Intelligent central control equipment, equipment group control method and device, and medium

Abstract

The invention relates to intelligent central control equipment, an equipment group control method and device and a medium, and the method comprises the steps: receiving an equipment group control request, and obtaining group generality description data and a to-be-executed control instruction in the equipment group control request; in response to the equipment group control request, equipment with semantic generality characteristics matched with the group generality description data is inquired from an equipment library to form an equipment logic group, and the equipment library is provided with semantic generality characteristics to which the equipment belongs corresponding to the equipment in a private network accessed by the local equipment; and issuing the control instruction to all devices of the device logic group. Through dynamic semantic matching, flexible and accurate group control of the intelligent equipment is realized.

Description

Technical Field

[0001] This application relates to the field of intelligent control, and in particular to an intelligent central control device, a method and apparatus for controlling device groups, and a medium. Background Technology

[0002] In the fields of smart home and IoT technologies, centralized control of multiple devices, i.e., group control, has become a key requirement for improving user experience and management efficiency. Traditional device group control methods mainly rely on pre-established static groups. Users need to manually select specific devices in the management interface and bind them to a fixed group, and subsequent control commands are uniformly issued to that group. This method is essentially a persistent encapsulation of a set of individual device identifiers.

[0003] This static group-based control method has inherent limitations. First, it lacks flexibility. Whenever devices in the physical environment change, such as adding or removing old devices, users must re-enter the settings interface and manually update the relevant group configurations, which is cumbersome and disrupts the user experience. Second, this method cannot support dynamic, on-demand grouping based on device attributes or functions. For example, when a user has a temporary control need, such as wanting to control all lighting devices in the living room or all appliances that support a specific brand, the traditional method requires these devices to already belong to a predefined group. If such a group does not exist, the user can only select devices one by one or is forced to create a new static group, which is extremely inconvenient in practical use.

[0004] A deeper technical problem lies in the fact that traditional methods cannot understand the abstract intent behind user commands, but merely mechanically execute pre-stored device lists. Their technical principles dictate that control logic is strongly coupled to the specific identities of devices, rather than being associated with their functions, locations, or other common characteristics. This results in the control system's inability to respond to semantically descriptive commands such as turning on all ambient lights or turning off all bedroom devices, severely limiting the potential for intelligent and natural interaction in group control.

[0005] Therefore, given the increasing number of IoT devices in home or office settings, there is an urgent need in this field for a novel group control method that can overcome the aforementioned shortcomings. This method would be able to dynamically identify and automatically form device groups based on the user's immediate intentions, thereby achieving smarter and more flexible device management and comprehensively improving the dynamic group control experience of network devices. Summary of the Invention

[0006] The primary objective of this application is to solve at least one of the above-mentioned problems by providing an intelligent central control device, a method and apparatus for controlling multiple devices, and a medium.

[0007] To achieve the various objectives of this application, the following technical solution is adopted: A device group control method provided for one of the purposes of this application includes the following steps: Receive device group control requests and obtain common group description data and control commands to be executed. In response to the device group control request, devices whose semantic common features match the group common description data are retrieved from the device library to form a device logical group. The device library is configured with the semantic common features to which each device belongs in the private network to which the local device is connected. The control command is issued to all devices in the device logic group.

[0008] An equipment group control device proposed for one of the purposes of this application, comprising: The request receiving module is configured to receive group control requests from devices and obtain common group description data and control instructions to be executed. The instant assembly module is configured to respond to the device group control request by querying the device library for devices whose semantic common features match the group common description data to form a logical device group. The device library is configured with the semantic common features to which each device belongs in the private network to which the local device is connected. The instruction application module is configured to issue the control instructions to all devices in the device logical group.

[0009] On another front, an intelligent central control device provided to suit one of the purposes of this application includes a camera unit and a controller, the controller including a processor and a memory, the camera unit being used to acquire and preview video streams, and the processor calling and running a computer program in the memory to execute the steps of the device group control method.

[0010] In another aspect, a computer-readable storage medium is provided to suit another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the described device group control method, which, when invoked by a computer, executes the steps included in the corresponding method.

[0011] Compared with traditional technologies, this application effectively overcomes the inherent limitations of traditional static group control methods by introducing a technical means of matching group common description data with the semantic common features of devices, achieving multiple positive effects, including but not limited to: First, this application significantly improves the flexibility and convenience of device group control. Because it no longer relies on a pre-bound static device list, but instead dynamically constructs logical device groups based on the common group description data carried in each request, it can instantly respond to users' temporary and diverse control needs. When devices are added or removed from the environment, users do not need to manually adjust the group configuration; it can automatically match based on the latest device library, greatly simplifying user operations and achieving a seamless device management experience.

[0012] Secondly, this application implements dynamic, on-demand grouping capabilities based on semantic features. By setting common semantic features for each device in the private network and matching them with common group description data in user commands, the control logic is transformed from being strongly coupled with individual device identifiers to being associated with common features such as device function, location, and brand. This means that users can use intuitive natural language descriptions such as "living room lights" or "bedroom air conditioners" to express their control intentions, enabling the control system to automatically understand and filter all devices that match the description, completely changing the traditional mode of control that must be based on fixed groups.

[0013] Furthermore, this application brings true intent understanding capabilities to device group control. The control system implemented accordingly is no longer merely a mechanical tool executing pre-stored instructions, but rather capable of parsing the abstract meaning of user commands and dynamically and intelligently translating them into specific device control actions. This greatly expands the boundaries of group control applications, enabling them to adapt to more complex and personalized scenario requirements, bringing a qualitative leap to the human-computer interaction experience in the smart home and IoT fields, and laying a solid technical foundation for achieving natural and intelligent device management. Attached Figure Description

[0014] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a typical embodiment of the device group control method of this application; Figure 2 This is a schematic block diagram of the equipment group control device of this application; Figure 3 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0015] The device group control method claimed in this application is typically deployed in a local private network centered around a smart central control device. This private network usually refers to a relatively closed and trusted communication domain, such as a local area network (LAN) constructed by a home gateway, enterprise router, or dedicated smart hub, within which numerous smart devices to be managed are connected, such as lighting fixtures, air conditioners, curtain motors, environmental sensors, smart sockets, and audio-visual equipment. These devices connect to the network via wired or wireless means and interact with each other using various communication protocols such as Wi-Fi, Zigbee, and Bluetooth Mesh.

[0016] The intelligent central control device itself is also a type of intelligent device. Physically, it can manifest as a smart home hub, a high-performance gateway, or a constantly powered micro-server, serving as the core carrier of the method described in this application. Specifically, the method described in this application can be implemented as a computer program and deployed and run on the intelligent central control device, thereby enabling the intelligent central control device to function as a corresponding device control system. Users can then use the intelligent central control device to perform group control operations on devices within a private network.

[0017] The devices controlled by the method of this application can cover all intelligent devices within the entire private network, as long as they can interact with the intelligent central control device based on the corresponding communication protocol to transmit corresponding control commands.

[0018] The core idea of ​​this application is to utilize intelligent central control devices for centralized management and intelligent scheduling of devices within a private network. To achieve this, each intelligent device connected to the private network is pre-associated with its corresponding semantic common features. These semantic common features constitute a semantic profile of the device, used to describe attributes such as the device's nature, function, type, physical location, or brand. For example, a living room chandelier can be labeled with features such as "lighting equipment, living room, main light." The semantic common features of all devices are stored together in a device library, which can be maintained locally by the intelligent central control device to ensure low latency and privacy security.

[0019] Users initiate group control requests through the interactive interface provided by the smart central control device, such as a voice assistant, mobile application, or web console. This request carries common group description data and control commands to be executed. The common group description data expresses the commonalities of the group of devices the user wishes to control; it can be in the form of natural language commands, such as "turn on all the lights in the living room," or it can be preliminarily parsed structured parameters. The smart central control device is responsible for parsing the common group description data and matching it with the semantic common features of each device stored in the device library. This dynamically and on-demand constructs the logical group of devices targeted for this control operation, and then sends the control commands to each device in the logical group for execution.

[0020] It should be noted that the device logical group involved in this application is a temporary logical concept, not a static group that needs to be pre-created and persistently stored. Its lifecycle begins when the matching calculation is completed and ends after the control command is issued. This approach gives the device control system great flexibility, enabling it to respond instantly to various temporary and complex control needs. Furthermore, the matching process between semantic common features and group common description data is the key to achieving intelligent control in this application, allowing the control logic to be built on the device's functions and attributes, rather than being strongly bound to fixed device identifiers.

[0021] Having revealed the above-mentioned basic network architecture, core concepts, and operational processes, the following detailed description of the implementation of the technical solution claimed in this application is provided through several specific embodiments.

[0022] Please see Figure 1 In some embodiments, the device group control method of this application can be implemented as an application program running in the processor of the intelligent central control device. The method includes: Step S3100: Receive a device group control request and obtain the group common description data and the control instructions to be executed. Device group control requests can be initiated by users through the interactive interface provided by the intelligent central control device. This interface can be an application integrated on a mobile device, a web-based console, or a smart assistant that supports voice interaction. Users express their control intentions through the interactive interface. These intentions include at least two parts: first, descriptive information for filtering target devices, i.e., common group description data; and second, the specific operations expected to be performed on these target devices, i.e., control commands.

[0023] In one embodiment, the group commonality description data can be natural language phrases or sentences directly input by the user. For example, the user can say "Turn on all the lights in the living room" or enter "Turn off the bedroom air conditioner" in a text box. In this case, the intelligent central control device can first parse the natural language and extract key control parameters. In another embodiment, the interactive interface can also provide a structured input method. For example, the user can combine their control objectives by checking device types, selecting the room area, etc., and then the device control system of the intelligent central control device generates structured group commonality description data, which is essentially a set of structured parameters that can be mapped to corresponding words or identifiers.

[0024] Control commands specify the actions to be performed on a target device, and their form is usually closely related to the device's functionalities. Control commands can be simple on / off commands, such as "turn on" or "turn off," or complex commands with specific parameter values, such as adjusting the air conditioner to 26 degrees Celsius or setting the light brightness to 50%. The command needs to match the functions that the target device can understand and perform. Along with group commonality description data, control commands can also be included in natural language phrases or sentences input by the user during live streaming, or they can be presented in a structured format for the user to select or confirm.

[0025] The intelligent central control device continuously monitors user operations through its integrated communication interface and interactive interface. When a user submits a device control command, the device group control request is received as a complete data packet. This data packet can be encapsulated in a specific application layer protocol format, such as an HTTP-based RESTful API request, an MQTT message, or serialized data from inter-process communication within the device. The intelligent central control device parses this data packet to separate the group's common descriptive data and control commands that constitute the core content of the request. The parsing process includes protocol decoding, data field extraction, and necessary format conversion. For example, for requests initiated by a voice assistant, the audio stream must first be converted into text in real time, and then natural language understanding processing is performed, including but not limited to word segmentation and named entity recognition to match the corresponding common vocabulary and the various operation actions and specific parameter values ​​required for the device control commands; while for structured requests initiated by applications or web consoles, JSON or similar format data objects are directly parsed, predefined descriptive fields and command parameters are extracted, and restored to the corresponding group common descriptive data and device control commands. After parsing, the clearly separated group common descriptive data and control commands can be processed subsequently.

[0026] Step S3200: In response to the device group control request, retrieve devices from the device library whose semantic common features match the group common description data to form a device logical group. The device library is configured with the semantic common features to which each device belongs in the private network to which the local device is connected. The intelligent central control device maintains a device database that records the semantic profile of each intelligent device within its private network. The database may include one or more common semantic features configured for each device. These features collectively constitute the semantic profile of the device, enabling intelligent retrieval and grouping. Semantic common features are abstract descriptions of the device's intrinsic attributes or external relationships. In various optional embodiments, these features can be formed through factory presets, manual user configuration, or automatic identification and annotation by the intelligent central control device using historical data generated from user interaction events.

[0027] Semantic common features come in various types, covering dimensions such as device function, location, category, brand, and even user-defined tags. One type is device type features, used to describe the core functions of the device, such as lighting equipment, air conditioners, curtain motors, and sensors. Another type is spatial location features, used to indicate the physical or logical deployment location of the device, such as living room, master bedroom, and kitchen. Brand and model features can also be included, such as brand A and model X, as well as functional attribute features, such as dimming, colored lighting, and temperature control. For example, a smart light can be assigned multiple semantic common features such as lighting equipment, living room, main light, and adjustable color temperature. Furthermore, there can be user-defined abstract types, such as abstract concepts related to indicator lights like "those lights," "ambience," and "too dark"; abstract concepts related to indicating silence, such as "going to sleep," can be semantic common features for various lights and audio-visual devices, implying that lights need to be turned off and audio-visual devices need to be shut down. All of these can be set as semantic common features of devices.

[0028] When the intelligent central control device responds to a device group control request and parses the common description data of the group, it initiates a matching process to query the device database for devices whose semantic common features match the description data, thereby dynamically constructing a logical device group. The core of the matching process lies in calculating the semantic correlation between the common description data of the group and the semantic common features of the devices. In one embodiment, semantic similarity calculation based on word vectors can be used. Under this scheme, a word embedding model needs to be pre-trained or invoked to map the set of common words in the common description data of the group and the set of semantic common features of the devices to high-dimensional vector spaces, respectively. Then, the cosine similarity or Euclidean distance between their corresponding vectors is calculated as the basic matching score.

[0029] In another embodiment, semantic matching based on a knowledge graph can be employed. This approach requires constructing a knowledge graph containing device domain concepts and relationships. During matching, common descriptive data of groups and device semantic features are treated as entities or concepts in the graph, and the degree of matching is evaluated by calculating their semantic distance in the graph or path-based relevance. For example, ambient lighting in the descriptive data and decorative lighting in the device features may belong to similar concepts in the knowledge graph, thus obtaining a higher matching score.

[0030] Another embodiment involves a direct keyword matching and weighted scoring strategy. In this relatively simplified approach, descriptive data is compared with device features using keywords, and the number of matches is counted. Subsequently, weights are assigned to different matches based on the importance of feature types (e.g., device type has a higher weight than brand and model), and finally, a comprehensive matching score is obtained by weighted summation.

[0031] Regardless of the specific matching algorithm used, the ultimate goal is to generate a quantified matching score, or device candidate score, for each device in the device library. Target devices are then selected from the library based on this score. For example, a threshold is set, and devices with scores higher than that threshold are selected, or the top N devices with the highest scores are selected, thus forming the logical group of devices corresponding to this request.

[0032] It is important to emphasize that a device logical group is a logical collection temporarily constructed in response to a specific request. Its lifecycle begins when the matching is completed and ends when the control command is issued. It is not a static group that needs to be persistently stored.

[0033] Step S3300: Send the control command to all devices in the device logic group.

[0034] After the dynamic construction of the device logic group is completed, control commands can be accurately and efficiently transmitted to each device in the group, and the commands can be executed correctly.

[0035] In one embodiment, the intelligent central control device interacts with devices within a private network through various supported communication protocols. Control commands can be issued following specific application-layer protocols defined by the device manufacturer. For example, for smart lighting fixtures supporting Wi-Fi, commands can be encapsulated as HTTP or MQTT messages and sent to the device's corresponding network endpoint; for devices using low-power wireless communication protocols such as Zigbee or Z-Wave, commands are forwarded after protocol conversion through the appropriate gateway. The intelligent central control device can maintain a device communication mapping table, which records each device's unique identifier, communication address, required protocol type, and other key information, thereby ensuring that commands can be accurately routed.

[0036] During the command issuance process, network reliability and device response status need to be considered. In one embodiment, a transmission method with an acknowledgment mechanism can be used. That is, after the intelligent central control device sends a control command to the target device, it waits for the device to return an acknowledgment signal confirming successful execution. If no acknowledgment is received within a preset timeout period, the intelligent central control device can retry a limited number of times, or record the failure, and may report the execution status to the user interface. In another embodiment, for scenarios where real-time requirements are not high or eventual consistency is acceptable, a one-way broadcast or multicast method without acknowledgment can also be used to issue commands to improve efficiency.

[0037] Furthermore, the issuance of commands may not be a simple atomic operation, but rather includes preprocessing and optimization. In one embodiment, before issuing control commands to all devices in a device logical group, the intelligent central control device can first query the real-time status of each device within the group. The expected result of the control command is compared with the current status of the devices. If the comparison finds that the current status of a device already matches the expected result of the command—for example, if the command is to turn off a light and the light is already off—then the command can be skipped, thus avoiding unnecessary network communication and device operations, saving resources and improving response speed. Only when the current status of a device does not match the expected result is the control command actually issued to that device.

[0038] Once the command is successfully issued and executed, the entire device group control process is complete. This mechanism ensures the ultimate implementation of the user's control intentions while balancing execution reliability and system efficiency.

[0039] This application fundamentally revolutionizes the traditional device control mode by introducing a technique of dynamically matching common group description data with common device semantic features, bringing significant technical advantages in several aspects, including but not limited to: First, the method described in this application significantly improves the flexibility and adaptability of device group control. Traditional technologies rely on pre-created static device groups, which cannot respond to real-time changes in the device environment. In contrast, this application dynamically constructs logical device groups by querying the device library in real-time with each request, enabling the control system to automatically adapt to the addition, removal, or status changes of devices. Users no longer need to manually maintain static groups; the control system always matches based on the latest device library status, thus achieving seamless device management and a zero-maintenance experience, completely solving the group failure problem caused by device changes in traditional methods.

[0040] Secondly, this application achieves true on-demand dynamic grouping capability. In traditional technologies, control logic is strongly bound to fixed device identifiers, requiring users to operate using predefined group names. This application, however, builds control logic on the semantic common characteristics of devices, enabling users to express control intentions using intuitive, function- or location-based, or even abstract descriptive language. For example, users do not need to pre-create a "living room light group"; they only need to say "turn on the living room lights," and the control system can automatically filter out all lighting devices located in the living room. This semantic-based dynamic matching mechanism liberates users from tedious group management work, achieving a fundamental shift from managing groups to expressing intentions.

[0041] Furthermore, this application significantly expands the semantic expression scope and intelligence level of group control operations. Traditional technologies are limited to executing preset, limited group control scenarios. This application, through semantic matching, can understand and respond to a large number of undefined, temporary, and complex control needs. Users can control not only "all living room devices," but also specify combinations of conditions across any dimension, such as "all air conditioners of brand A" or "all lighting devices." By parsing common description data of the group, these abstract instructions can be understood and target devices accurately matched, enabling the control system to evolve from a mechanical tool that can only execute fixed commands into an intelligent agent capable of understanding the user's generalized intentions.

[0042] Finally, this application lays a solid foundation for building an efficient and reliable control system. By centrally maintaining the device library locally on the intelligent central control device and based on a clear description-to-execution process, this application ensures low latency and high reliability in the issuance of control commands. The method of dynamically constructing device logical groups avoids the storage overhead and management complexity caused by maintaining a large number of static groups, and can efficiently support the complex control needs of large-scale device networks, providing core technical support for the large-scale deployment of smart home and IoT applications.

[0043] Based on any embodiment of the method in this application, devices whose semantic common features match the common description data of the group are queried from the device library to form a logical group of devices, including: Step S3210: For each common word contained in the group common description data, calculate the semantic similarity between it and each semantic common feature of each device in the device library, and use it as the basic similarity score; To achieve fine-grained semantic correlation quantification of user intent and device features, in this embodiment, for the parsed group common description data, each common word contained therein is independently compared with each semantic common feature of each smart device in the device library. The output results are a series of basic similarity scores, providing a data foundation for subsequent weighted fusion and device screening.

[0044] In one embodiment, semantic similarity can be calculated based on a word embedding model. For this purpose, a word embedding model trained on a large-scale corpus, such as Word2Vec, GloVe, or a Transformer-based model, is pre-trained or invoked. During calculation, a common word from the group's common description data, such as "living room," and a semantic common feature of the devices, such as "bedroom," are input into the model to obtain their distributed representations in a high-dimensional vector space. Subsequently, the cosine similarity or Euclidean distance between these two vectors is calculated to obtain a value between 0 and 1, which serves as the basic similarity score between the word and the feature. For example, the similarity between "living room" and "bedroom" might be high, while the similarity between "living room" and "air conditioner" might be low.

[0045] In another embodiment, a semantic similarity calculation method based on knowledge graphs can be employed. This utilizes a structured knowledge base containing device domain concepts and relationships. During calculation, common vocabulary and device features are mapped to entity or concept nodes in the knowledge graph. The degree of similarity is quantified by calculating the length of the shortest path between them or by calculating their semantic relevance based on information content. For example, in a knowledge graph, a chandelier and lighting equipment have a direct hierarchical relationship, resulting in high semantic similarity; while the living room and kitchen, as parallel location concepts, have relatively low similarity.

[0046] Another implementation, suitable for scenarios with lower computational resource requirements, employs string matching-based similarity calculation. This method directly compares the similarity between common words and the device feature strings themselves, for example, using edit distance algorithms or the Jaccard similarity coefficient. Although this method cannot understand deep semantics, it can still serve as an effective implementation for scenarios where feature words are highly standardized and have consistent expressions.

[0047] Regardless of the specific algorithm used, this step generates a basic similarity score matrix for each device in the device library. The rows of this matrix correspond to each common word in the group common description data, the columns correspond to each semantic common feature of the device, and each element value in the matrix represents the association strength between a specific word and a specific feature as measured by the algorithm.

[0048] Step S3220: For each device in the device library, perform weighted fusion of all basic similarity scores corresponding to the device to generate a candidate device score corresponding to the common description data of the group. After the basic similarity score is calculated, the scattered and fine-grained basic similarity scores for individual devices are aggregated into a single quantitative indicator that can comprehensively reflect the overall matching degree between the device and the common descriptive data of the entire group, namely the device candidate score. Specifically, this can be achieved by performing a weighted fusion operation on the basic similarity score matrix of each device.

[0049] The basis for weighted fusion lies in recognizing that different semantic common features have varying importance for device identification, and that the intensity of intent expressed by different common words in the group common description data also differs. Therefore, a simple arithmetic average cannot accurately reflect this hierarchy of importance. In one embodiment, the fusion process introduces two weights: feature weights for semantic common features and lexical weights for common words parsed from the group common description data. Feature weights are used to distinguish the importance of different features of the device itself; for example, the weight of the device type feature "lighting device" is usually higher than the weight of its brand feature "brand A". Lexical weights are used to distinguish the degree of emphasis of different words in user commands; for example, the weight of "living room" as a location constraint in a user description may differ from the weight of "main light" as a functional constraint.

[0050] The specific weighted fusion operation can be described as follows: for a specific device, multiply each of its basic similarity scores by the feature weight of the specific semantic common feature corresponding to that score, and the word weight of the specific common word associated with that score. This calculation traverses all basic similarity scores of the device, that is, it covers the scores between all words in the group common description data and all semantic common features of the device. In one embodiment, the final device candidate score can be obtained by summing all weighted results, that is, calculating the weighted sum. This fusion strategy considers the contribution of all matching paths and is suitable for scenarios that require a comprehensive evaluation of device matching degree.

[0051] In another embodiment, when it is necessary to emphasize the matching degree of the device on a certain core dimension, a fusion strategy of taking the maximum value can be adopted. That is, among all weighted basic similarity scores, the one with the largest value is selected as the final candidate device score. This approach ensures that as long as the device highly matches the instruction on any key feature, it can obtain a high candidate score, which is suitable for scenarios with ambiguous instructions or emphasizing a single feature.

[0052] Through the weighted fusion described above, a unified and comparable candidate device score is generated for each device in the device library. This score quantifies the overall probability that the device conforms to the intent expressed by the common descriptive data of the current group, providing a direct decision-making basis for subsequent accurate screening of target devices and construction of logical device groups.

[0053] Step S3230: Based on the device candidate scores of all devices, select target devices from the device library to form the device logical group corresponding to the device group control request.

[0054] After calculating the candidate device score for each device in the device library, the final screening of target devices and the construction of device logic groups are carried out. Based on the unified quantitative indicator of the candidate device score, the devices in the device library are accurately determined to be included in the target set of this control operation.

[0055] The filtering strategy can be implemented by setting a reasonable selection threshold or selection rule. In one embodiment, an absolute threshold method can be used. That is, a minimum threshold value for the candidate device score is preset, and all devices in the device library with a candidate score higher than this threshold are filtered out to form the logical group of devices for this request. For example, if the threshold is set to 0.7, then all devices with a score greater than 0.7 will be selected. This method is suitable for scenarios with high matching accuracy requirements and where it is necessary to explicitly exclude low-relevance devices.

[0056] In another embodiment, a relative ranking method can be used. This method does not consider the absolute numerical value of the scores, but rather sorts all devices based on their scores and selects the top-ranked devices. For example, it can directly select the device with the highest candidate score, or select the top N devices to form a group. This approach is suitable for scenarios where it is necessary to control the group size or maintain a relatively stable number of devices in the group across different requests, such as always controlling the device with the highest matching score or five devices.

[0057] Furthermore, the two methods mentioned above can be combined to form a hybrid screening strategy. For example, a minimum absolute threshold can be set first, and only devices with scores higher than this threshold can be included in the candidate pool. Then, the top N devices in this candidate pool can be selected based on their scores. This approach combines the advantages of an absolute threshold and quantity control, effectively managing the size of the group while ensuring basic matching quality.

[0058] Finally, based on the selected filtering strategy, the list of target devices determined from the device library is used to form the logical group of devices corresponding to this device group control request.

[0059] To deepen understanding of this embodiment, an application scenario is presented. In this scenario, a user commands the smart central control device to "turn off the yellow lights." The control system first processes this command using a named entity recognition model, identifying two core common words: "yellow" and "light." In terms of word weight allocation, "light" explicitly indicates the device type and is the core control object, thus receiving a higher word weight (e.g., 0.9); while "yellow," as a specific modification of the device attribute, has a slightly lower weight (e.g., 0.7). In the device library, a color-adjustable smart light is labeled with multiple semantic common features and assigned feature weights, such as "lighting equipment" (feature weight 0.95), "living room" (feature weight 0.8), and "adjustable color temperature" (feature weight 0.6). The control system calculates that "light" and "lighting equipment" have extremely high semantic similarity, both with high weights, and also calculates that "yellow" and "adjustable color temperature" have a significant semantic association. After weighted fusion, this color-adjustable light receives a high device candidate score, thus being accurately selected into the device logical group. Ultimately, the device that matched the user's abstract description of "yellow light" was successfully located and turned off, while other white lights without color adjustment functions were not selected. This effectively enabled users to precisely control the desired target device even when using vague, attribute-based abstract concepts.

[0060] Through the complete application of the above embodiments, this application has achieved significant technical advantages. First, by introducing a multi-level weighted fusion mechanism of basic similarity scoring, feature weights, and word weights, the originally qualitative semantic matching problem is transformed into a precise quantitative calculation process. This allows the correlation between devices and user intent to be objectively measured and compared, fundamentally avoiding the arbitrariness and ambiguity of traditional keyword-based matching. Second, the device candidate scoring-based screening strategy provides a scientific and flexible decision-making basis for constructing device logical groups. This enables the control system not only to identify highly matching devices but also to adaptively adjust the group range according to scenario requirements, achieving a leap from matching to optimal matching. Ultimately, this ensures that even when users use abstract and fuzzy natural language commands, they can accurately control the specific device group that their true intent refers to.

[0061] Based on any embodiment of the method in this application, for each device in the device library, a weighted fusion of all basic similarity scores corresponding to that device is performed, including: Step S3221: Process the common description data of the group through the named entity recognition model to identify the entity words that constitute the common vocabulary and the corresponding entity types; After calculating the basic similarity score, a weighted fusion of all scores for each device is needed to generate a candidate device score that comprehensively reflects the degree of matching between the device and the overall common descriptive data of the group. To this end, the common descriptive data of the group is first processed using a pre-trained named entity recognition model. This model can identify the entity words that constitute the common vocabulary in the descriptive data and their corresponding entity types. In one embodiment, a pre-trained sequence labeling model, such as a BERT-based model, can be used to segment the input text and perform entity recognition, classifying words into predefined entity types, such as device type entities, spatial location entities, attribute entities, and abstract concept entities. For example, for the instruction "turn on the living room light," the model can identify "living room" as a location entity and "light" as a device type entity.

[0062] Step S3222: Based on the preset relationship data representing the mapping relationship between entity type and word weight, set the word weight of each entity word according to the entity type to which each entity word belongs; After identifying entity types, a word weight is assigned to each entity word based on a predefined mapping relationship between entity types and word weights. This mapping relationship defines the relative importance of different entity types in the matching process. In one embodiment, this can be achieved by querying a predefined weight configuration table, which assigns a base weight value to each entity type. For example, device type entities typically directly indicate the category of the target device and may therefore be assigned a higher weight, such as 0.9; spatial location entities define the location range of the device and may have a lower weight, such as 0.8; while attribute entities (such as color and size) may serve as auxiliary conditions and have a relatively lower weight, such as 0.6. Similarly, the specific value of the word weight can be adjusted and optimized based on domain knowledge or historical interaction data.

[0063] Step S3223: Multiply each basic similarity score by the feature weight of the semantic common feature corresponding to the score and the word weight of the common words corresponding to the score to obtain the updated similarity score; Next, the updated similarity score is calculated. Each base similarity score is multiplied by the feature weight of the specific semantic common feature corresponding to that score, and the lexical weight of the specific common word associated with that score. The feature weight represents the importance of the device feature itself, while the lexical weight represents the importance of that word in the user command. The result of multiplying these three factors is the updated similarity score, which considers semantic matching, feature importance, and lexical importance simultaneously. For example, if a base similarity score is 0.8 (indicating good matching), the corresponding feature weight is 0.9 (indicating the feature is important), and the corresponding lexical weight is 0.8 (indicating the word is important in the command), then the updated similarity score is 0.8 * 0.9 * 0.8 = 0.576.

[0064] Step S3224: Merge all updated similarity scores for each device to generate the corresponding device candidate score.

[0065] Finally, all updated similarity scores for each device are merged to generate the final candidate device score. The purpose of fusion is to aggregate the scattered scores for different word-feature pairs into a single value representing the overall matching degree. In one embodiment, a weighted summation method is used for fusion, that is, all updated similarity scores for the device are summed. This method considers the contribution of all matching paths and can comprehensively evaluate the matching degree of the device. In another embodiment, when the instruction intent is relatively ambiguous or more attention is paid to the strongest matching signal, the maximum value method can be used, that is, the maximum value among all updated similarity scores can be selected as the candidate device score. This method ensures that as long as the device highly matches the instruction in any dimension, it will obtain a high score.

[0066] Through the complete application of the above embodiments, this application further achieves technical advantages in improving the rationality and interpretability of matching decisions. By introducing entity type-based lexical weights and working in conjunction with feature weights in similarity scoring, the final device candidate score not only reflects the semantic level of association strength but also incorporates quantitative considerations of user intent emphasis and device feature importance. This upgrades the device selection process from a simple similarity comparison to a weighted, multi-factor intelligent decision-making process, significantly improving the accuracy of group construction and adaptability to complex instructions.

[0067] Based on any embodiment of the method in this application, the updated similarity scores of each device are fused to generate a candidate device score for that device, including: Step S4100: Extract the data feature set of the entity type set obtained after named entity recognition, the data feature set including: whether there is a device type entity and whether there is a spatial location entity; After completing the named entity recognition of the common descriptive data of the group, we can continue to extract the key data feature set of the entity type set obtained after named entity recognition, in order to characterize the structural features of the instruction. This data feature set mainly includes, but is not limited to, the following Boolean features: whether there is a device type entity and whether there is a spatial location entity. These features directly reflect the explicitness and specificity of the user instruction. For example, if an instruction contains both a device type entity (such as a lamp) and a spatial location entity (such as a living room), it indicates that the user intends to explicitly point to a specific device category at a specific location.

[0068] Step S4200: Detect the set of entity types obtained after named entity recognition to determine the instruction pattern, wherein: if both location type entities and device type entities exist in the set, it is determined to be a precise multi-condition instruction pattern; otherwise, it is determined to be a fuzzy single-point instruction pattern. Based on the extracted data feature set, the control system performs command pattern detection to determine the current command pattern. Specifically, the detection logic is as follows: If the entity type set obtained after named entity recognition contains both location-type entities and device-type entities, the current command is determined to be a precise multi-condition command pattern. This pattern typically corresponds to a highly explicit control intent, such as "turn off the living room lights." Conversely, if the entity type set does not contain both types of entities simultaneously—for example, only device-type entities (e.g., turning on the lights) or only attribute-type entities (e.g., brightening the lights)—the current command is determined to be a fuzzy single-point command pattern. This pattern typically corresponds to a relatively broad control intent or one that emphasizes a specific attribute.

[0069] Step S4300: If the device is determined to be the precise multi-condition instruction mode, a weighted summation fusion strategy is adopted to accumulate all the updated similarity scores corresponding to the device to generate the device candidate score. When the system is identified as a precise multi-condition command mode, it indicates that the user command includes explicit constraints such as location and device type, for example, turning off the living room lights. In this case, the control system employs a weighted summation fusion strategy. The core of this strategy is to sum all the updated similarity scores corresponding to the device. The updated similarity score is the result after weighting by feature weights and word weights, already including the relative importance of each matching dimension. Through summation, the overall matching degree of the device across all relevant dimensions can be comprehensively examined. In one embodiment, the summation process can be viewed as a linear combination, where each score represents the contribution of a matching path, and the summation yields the comprehensive score. This strategy ensures that the device needs to achieve good matching across multiple key dimensions such as location and type to obtain a high score, making it suitable for precise control scenarios that require simultaneous fulfillment of multiple conditions.

[0070] Step S4400: If the device is determined to be the fuzzy single-point instruction mode, the maximum value filtering and fusion strategy is adopted to take the maximum value among all updated similarity scores corresponding to the device as the candidate score of the device.

[0071] If the instruction is determined to be a fuzzy single-point command pattern, it indicates that the user command's constraints are relatively broad or focus on a single attribute, such as turning on a light or brightening it slightly. In this case, a maximum value filtering and fusion strategy is adopted. The core of this strategy is to take the maximum value among all updated similarity scores corresponding to the device as the candidate device score. The maximum value strategy focuses on the strongest matching signal of the device in a specific dimension. In one embodiment, all scores are traversed and the one with the largest value is selected. This strategy is suitable for scenarios where the device only needs to be highly matched in any dimension to meet the requirements, and it can effectively capture the most prominent intent features of the user command.

[0072] In the above embodiments, this application uses an adaptive selection fusion algorithm by analyzing the entity composition features of instructions. Instead of a fixed, one-size-fits-all matching strategy, it intelligently distinguishes between precise multi-condition control scenarios and fuzzy single-point control scenarios, employing weighted summation and maximum value filtering—two fusion methods whose mathematical properties are highly compatible with scenario requirements. This context-aware capability allows the device candidate scores to more accurately reflect the matching essence under different scenarios, ensuring comprehensive evaluation under multiple constraints while strengthening targeted identification in single-point focused scenarios. This, in turn, enhances the intelligence and precision of device group control at a higher level.

[0073] Based on any embodiment of the method in this application, after issuing the control command to all devices in the device logic group, the method includes: Step S5100: Obtain device group control requests and their application result data generated by the user's previous interactions. The application result data includes the result of whether the control command of the corresponding device group control request was successfully executed. After control commands are issued to all devices in the logical device group, a continuous learning and optimization cycle can be initiated. This involves collecting corresponding feedback data to obtain complete records of device group control requests generated during each user interaction, along with their corresponding application result data. This provides a data foundation for subsequent self-optimization of the semantic feature library. Application result data is crucial information for determining the final execution effect of each control request, accurately recording and characterizing whether the control commands contained in the corresponding device group control request were successfully executed on the target device.

[0074] The acquisition of application result data can be achieved through various technical approaches. In one embodiment, an instruction execution confirmation mechanism can be employed. After the intelligent central control device sends a control instruction to the target device, it simultaneously initiates a listening process, waiting for the device to return an execution confirmation signal. This signal is typically sent proactively by the device after successfully executing the instruction. For example, when a smart light successfully turns off, it returns an "operation successful" confirmation message to the intelligent central control device. If the intelligent central control device receives this message within a preset timeout period, it records that the control instruction was successfully executed. If no confirmation is received within the timeout period or an "operation failed" message is received, it is recorded as unsuccessful execution.

[0075] In another embodiment, a status query verification mechanism can be employed. After issuing a control command, the intelligent central control device does not rely on the device's active confirmation, but instead actively queries the real-time status of the target device after a short delay. The effectiveness of the command is determined by comparing the current status returned by the device with the expected result of the control command. For example, if the control system issues a "turn off the air conditioner" command, it waits a few seconds and then queries the air conditioner's on / off status. If the status is "off," the command is considered successfully executed; if the status is still "on," the execution is considered unsuccessful. This method does not depend on whether the device supports confirmation messages, making it more adaptable.

[0076] Furthermore, the generation of application result data can also incorporate user interaction feedback. In one embodiment, after the control command is issued, a simple feedback entry point can be provided through the user interface, such as a prompt asking "Was the operation successful?". Users can directly confirm the operation result by clicking "Yes" or "No," and this explicit feedback can serve as the most reliable result data. In another embodiment, implicit feedback can also be provided by monitoring the user's subsequent actions. For example, if the user manually turns on a light again very quickly after the control system sends a "Turn off all lights" command, it can be inferred that the previous group control command may not have fully met the user's expectations, and the credibility of this execution result needs to be flagged or adjusted.

[0077] The acquired application result data and corresponding device group control requests, including original group common description data, control commands, target device lists, etc., will be associated and stored to form a complete historical interaction record. This historical data constitutes samples for the system to perform self-learning, optimize the semantic feature library, and adjust feature weights, enabling the control system to continuously evolve from actual usage effects and improve the accuracy and intelligence level of subsequent device matching.

[0078] Step S5200: Perform word segmentation and statistical analysis on the common description data of each device group control request, and extract common words that appear more frequently than a preset threshold. After acquiring historical interaction data, statistical analysis is performed on the accumulated group common description data. By segmenting the group common description data in the group control requests of various devices, and extracting high-frequency common words based on word frequency statistics, representative semantic patterns frequently used by users are identified.

[0079] Before word segmentation and statistics, continuous descriptive text in the common descriptive data of the group is first divided into independent lexical units. In one embodiment, a dictionary-based word segmentation method can be used. A domain dictionary containing commonly used words related to device control, such as device type, spatial location, action commands, attribute descriptors, etc., is used. The descriptive data is scanned against the domain dictionary using maximum matching to segment words that conform to the dictionary specifications. In another embodiment, a statistical model-based word segmentation method can be used. A pre-trained word segmentation model is used to determine word boundaries based on the co-occurrence probability between characters. This method has better adaptability to out-of-vocabulary words and novel expressions.

[0080] After word segmentation, frequency statistics are performed on all words appearing in all historical requests, calculating the number of times each word appears. The scope of frequency statistics can be global, that is, counting the total number of times the word appears in all historical requests; or it can be device-specific, that is, counting the number of times the word appears in requests targeting a specific device or device type. The statistical results intuitively reflect the activity and importance of different words in user commands.

[0081] Finally, based on a preset frequency threshold, high-frequency words are selected from the statistical results as common words. The threshold can be set as an absolute number of occurrences, such as words appearing more than 10 times; or it can be set as a relative frequency, such as words appearing in the top 10% of the most frequent words. The extracted high-frequency common words represent the core semantic units that user groups or specific users habitually use to express control intentions.

[0082] Step S5300: Add the extracted common words as semantic common features to the semantic common feature library of the devices in their corresponding device logical groups; After extracting high-frequency common words, the dynamic expansion process of the semantic common feature library is initiated so that the identified high-frequency words can be added as new semantic common features to the feature library of the corresponding device in the historically associated device logical group, thereby enriching the semantic profile of the device.

[0083] Adding features requires clarifying their association with specific devices. In one embodiment, this association is established by tracing historical interaction records. When a common term is determined to be added, all device group control requests containing that term and marked as successfully executed are queried, and a list of the target devices ultimately controlled by these requests is obtained. The term will then be added to the semantic common feature libraries of these devices. For example, if the term "yellow" appears in multiple successful requests to control a smart light, then that term will be added as a semantic common feature of that light.

[0084] In another embodiment, a more conservative addition strategy can be adopted for high-frequency words that appear for the first time or are associated with many devices. For example, a device association frequency threshold can be set, and the word is only added as a feature of a specific device if the number of times it appears in successful requests for that specific device exceeds the threshold. This helps to avoid introducing noisy features due to accidental associations and ensures the purity and effectiveness of the feature library.

[0085] The addition of new features must adhere to the data structure of the feature library. In one embodiment, the semantic common feature library can be a feature list or feature set associated with each device. The addition operation involves inserting the new word string into the feature list of the corresponding device. Furthermore, each newly added feature is initially assigned a base feature weight, which can be a preset default value, such as a medium value, to play a role in subsequent matching calculations, while allowing for adjustment based on usage performance.

[0086] Step S5400: Based on the success rate of common words being used by users and corresponding control commands being successfully executed, adjust the feature weight of the semantic common feature corresponding to the common word in the semantic common feature library of the device.

[0087] After extracting high-frequency common words and dynamically expanding the feature library, the process enters the weight adaptive adjustment stage. Based on the effectiveness of common words in actual use, the feature weights of these words in the semantic common feature library of their respective devices are dynamically optimized, making the feature weights a quantitative indicator of the reliability of the association between the word and the device.

[0088] The weight adjustment can be based on the success rate of common terms being used by users and the corresponding control commands being successfully executed. The calculation of the success rate relies on historical interaction data. Specifically, for a common term added to a specific device feature library, the total number of times this common term appears in the group common description data of historical device group control requests is counted, along with the number of times the control commands were successfully executed in these requests. The success rate is the ratio of the number of successful executions to the total number of occurrences. For example, if the common term "atmosphere" in a device feature library was used to control the device 10 times in the historical record, with 8 successful executions, then its success rate is 0.8.

[0089] Based on the calculated success rate, the feature weights of the semantic common features corresponding to the common words are adjusted. In one embodiment, a direct mapping strategy can be adopted. That is, a pre-defined function relating success rate to feature weights is used. For example, a linear mapping rule can be set: when the success rate is 1.0, the feature weight is adjusted to the highest value of 1.0; when the success rate is below 0.5, the feature weight is reduced to a lower baseline value of 0.2; when the success rate is between 0.5 and 1.0, the weight increases linearly proportionally. This strategy is simple and direct, and the adjustment magnitude has a clear functional relationship with the success rate.

[0090] In another embodiment, an incremental adjustment strategy can be employed. Periodically, such as after accumulating a certain number of new interaction records, the feature weights are fine-tuned based on the difference between the recently calculated success rate and the current weight. For example, if the current success rate is higher than an expected threshold, the weight is adjusted upwards in a small, preset step; if the success rate remains consistently low, the weight is gradually reduced. This strategy allows the weights to smoothly adapt to changes in usage patterns, avoiding drastic fluctuations in weights due to a single instance of abnormal data.

[0091] The goal of the adjustment is to ensure that the feature weights accurately reflect the word's effectiveness and reliability as a device identifier. A word with a high success rate means that the user actually intends to control the device when using the word, and that control is often successful; therefore, it should be given a high weight and play a greater role in subsequent semantic matching. Conversely, a word with a low success rate may mean inaccurate association or a high risk of miscontrol; its weight should be reduced to minimize its interference with the matching results.

[0092] Through the above embodiments, this application further achieves a technical advantage of continuous self-optimization capability, specifically manifested in realizing an intelligent leap from static configuration to dynamic evolution. By obtaining execution result feedback from historical interaction data, and using the success rate of actual application as an objective evaluation indicator, the feature weights of semantic common features that have been mined and added to the device feature library are dynamically adjusted. This makes the semantic profile of the device no longer a fixed preset label, but a living model that can continuously self-calibrate based on actual usage effects. The weight of a semantic feature no longer depends on the initial setting, but is determined by the frequency with which it is used and successfully triggered by the user in actual control scenarios, thereby ensuring that the feature weight can truly reflect the reliability of the feature's association with the device and the stability of user usage habits. This weight adjustment mechanism based on empirical feedback can automatically strengthen high-frequency and accurate semantic associations, while weakening low-frequency or easily mis-controlled invalid or ambiguous associations. This continuously improves the accuracy of device matching and the correctness of user intent understanding in long-term operation, ultimately achieving a self-evolving effect of becoming smarter and more accurate with use.

[0093] Based on any embodiment of the method in this application, after issuing the control command to all devices in the device logic group, the method includes: Step S6100: Generate a unique group fingerprint based on the group commonality description data of the device group control request; After constructing the device logical group and issuing control commands, a caching mechanism can be activated to optimize the processing efficiency of subsequent requests. To this end, a unique group fingerprint is first generated for each successful group control request. The group fingerprint can be generated based on the common group description data of the request, using an irreversible hash algorithm or similar function to map the common group description data into a fixed-length, unique string identifier. In one embodiment, MD5 or SHA series algorithms can be used to hash the string of description data, ensuring that even subtle differences in description will produce distinct fingerprints, thereby avoiding mismatches. This group fingerprint serves as a unique identifier for this request and its corresponding device list.

[0094] Step S6200: Associate the device list of the device logical group with the group fingerprint and store it in the cache as a cache entry; After generating the group fingerprint, the list of specific devices included in the dynamically constructed logical device group of this device group control request is associated with the group fingerprint to form a complete cache entry, which is then stored in the cache. The cache entry can be stored in key-value pairs, where the group fingerprint is the key and the device list is the value. In one embodiment, the cache can be deployed in the memory of the intelligent central control device to achieve high-speed access. When storing in the cache, a time-to-live (TTL) can also be set for the entry to prevent the cache from occupying resources indefinitely.

[0095] Step S6300: Respond to the subsequently triggered device group control request, determine whether the group fingerprint generated by its group common description data hits the cache. When it hits, directly call the device list of the hit cache entries as the device logical group. When a new device group control request is triggered, a new group fingerprint is first generated using the same algorithm described earlier, based on the group's common description data. Then, the cache is queried to check if this newly generated group fingerprint already exists, i.e., if a cache hit occurs. If a hit occurs, it indicates that the semantic description of this request is highly consistent with a successful historical request. The device list stored in the hit cache entry is directly used as the logical device group for this request, thus completely skipping the time-consuming semantic matching calculation process and greatly improving response speed.

[0096] Step S6400: When a change is detected in the devices in the device list or in the semantic common features of the devices, the cache entry corresponding to the device list in the cache is automatically deleted.

[0097] To ensure consistency between cached data and the actual device state, it is necessary to monitor changes in devices or their semantic common characteristics and automatically clean up related cache entries when changes occur. The monitoring mechanism can be event-driven, for example, proactively issuing notifications when a device comes online, goes offline, or its semantic characteristics are reconfigured by the user; or it can be periodic polling, periodically checking device status or the version number of the feature library. Once a change in a device or its semantic common characteristics is detected, the cache can be traversed to find and delete all cache entries in the device list containing that device. This fine-grained invalidation mechanism ensures response speed while strictly preventing the return of outdated or incorrect device lists due to changes in device state.

[0098] Through the complete application of the above embodiments, this application further achieves significant technical advantages in improving system response efficiency and ensuring strong data consistency. The introduction of the caching mechanism transforms highly repetitive semantic matching calculations into one-time calculations and multiple high-speed queries. Especially for frequently used commands, it enables near-instantaneous responses, greatly improving the user experience. Simultaneously, the uniqueness of group fingerprints ensures query accuracy, and an intelligent cache invalidation mechanism ensures strict synchronization between cached data and real-time device status. This allows the control system to achieve a significant performance improvement while avoiding control errors caused by data expiration, achieving a balance between high efficiency and reliability. This provides key technical support for large-scale, high-frequency device group control applications.

[0099] Based on any embodiment of the method in this application, the control command is issued to all devices in the device logic group, including: Step S3310: Query and determine the real-time status of each device in the device logical group; Before issuing control commands to the device logic group, the real-time status of each device within the group is first queried to obtain the latest operating status. In one embodiment, the intelligent central control device can obtain the status through active querying, i.e., sending a status query request to the target device and waiting for the device to return its current operating parameters, such as querying the on / off status and brightness value of a smart light, or querying the set mode and current temperature of an air conditioner. In another embodiment, for devices that support status reporting, the intelligent central control device can listen for status change messages actively reported by the device and maintain a device status cache locally, directly reading the real-time status from the cache. This method has a faster response speed. Real-time status data is the basis for determining whether subsequent control commands need to be executed.

[0100] Step S3320: Compare the expected result of the control command with the real-time state. If the comparison result is consistent with the real-time state, then cancel sending the control command to the device. After obtaining the real-time status, the expected result of the control command is compared with the real-time status of the device. The expected result refers to the state the device should reach after the control command is successfully executed. For example, the expected result of a "turn off" command is that the device is off, and the expected result of a "adjust brightness to 50%" command is that the device brightness is 50%. The comparison logic determines whether the expected result matches the real-time status. If the comparison result matches, it means that the current state of the device already meets the command objective, and there is no need to repeat the same operation; the control command can be cancelled. For example, if the command is to turn off a light, and the light is found to be off, the "turn off" command is cancelled. This comparison effectively avoids redundant operations.

[0101] Step S3330: If the comparison result is inconsistent with the expected result and the real-time state, continue to send the control command to all devices in the device logic group.

[0102] If the comparison result shows a discrepancy between the expected result and the real-time status, it indicates that the current state of the device does not meet the requirements of the control command, and control needs to be executed to change the device state. In this case, the normal command issuance process continues, issuing a control command to the device. For example, if the command is to turn off a light, but the light is found to be on, the command to turn off is issued normally. This ensures that control commands are only sent to devices whose states have not yet reached the target, thereby achieving precise control.

[0103] In the above embodiments, this application, through a pre-instruction status check and comparison mechanism, can intelligently identify and skip unnecessary redundant control operations, avoiding the repeated sending of instructions to devices already in the target state. This saves network bandwidth and device energy consumption, reduces device losses caused by processing invalid instructions, and improves response efficiency and the rationality of control operations. This mechanism enables the control system to possess status perception and decision-making capabilities, upgrading it from simply executing instructions to intelligent decision-making based on device status, reflecting a higher level of automation and intelligence.

[0104] Please see Figure 2 This device group control apparatus, provided to meet one of the purposes of this application, is a functional embodiment of the device group control method of this application. The apparatus includes a request receiving module 3100, an instant assembly module 3200, and an instruction application module 3300. The request receiving module 3100 is configured to receive device group control requests and obtain common group description data and control instructions to be executed. The instant assembly module 3200 is configured to, in response to the device group control request, query a device library to find devices whose semantic common features match the common group description data, thus forming a logical device group. The device library is configured to set semantic common features corresponding to each device in the private network accessed by the local device. The instruction application module 3300 is configured to issue the control instructions to all devices in the logical device group.

[0105] Based on any embodiment of the device in this application, the instant assembly module 3200 includes: a similarity calculation module, configured to calculate the semantic similarity between each common word contained in the group common description data and each semantic common feature of each device in the device library, as a basic similarity score; a weighted fusion module, configured to perform weighted fusion of all basic similarity scores corresponding to each device in the device library to generate a device candidate score corresponding to the group common description data; and a device filtering module, configured to filter target devices from the device library based on the device candidate scores of all devices to form a device logical group corresponding to the device group control request.

[0106] Based on any embodiment of the device in this application, the weighted fusion module includes: an entity recognition module, configured to process the group common description data through a named entity recognition model to identify the entity words constituting the common vocabulary and their corresponding entity types; a vocabulary weighting module, configured to set the vocabulary weight of each entity word according to the entity type to which each entity word belongs, based on preset relationship data representing the mapping relationship between entity types and vocabulary weights; a score update module, configured to multiply each basic similarity score by the feature weight of the semantic common feature corresponding to the score and the vocabulary weight of the common vocabulary corresponding to the score to obtain an updated similarity score; and a score fusion module, configured to fuse all updated similarity scores of each device to generate a device candidate score corresponding to the device.

[0107] Based on any embodiment of the device in this application, the scoring fusion module includes: a feature extraction module, configured to extract a data feature set of the entity type set obtained after named entity recognition, the data feature set including: whether a device type entity exists and whether a spatial location entity exists; a pattern detection module, configured to detect the entity type set obtained after named entity recognition to determine the instruction pattern, wherein: if both location type entities and device type entities exist in the set, it is determined to be a precise multi-condition instruction pattern; otherwise, it is determined to be a fuzzy single-point instruction pattern; a first fusion module, configured to, if determined to be the precise multi-condition instruction pattern, use a weighted summation fusion strategy to accumulate all updated similarity scores corresponding to the device to generate the device candidate score; a second fusion module, configured to, if determined to be the fuzzy single-point instruction pattern, use a maximum value filtering fusion strategy to take the maximum value among all updated similarity scores corresponding to the device as the device candidate score.

[0108] Based on any embodiment of the device in this application, following the instruction application module 3300, the device further includes: a history call module, configured to acquire device group control requests and their application result data generated by user interactions, wherein the application result data includes results indicating whether the control instructions of the corresponding device group control requests were successfully executed; a word segmentation and statistics module, configured to perform word segmentation and statistics on the group common description data of each device group control request, and extract common words whose frequency of occurrence is higher than a preset threshold; a word entry module, configured to add the extracted common words as semantic common features to the semantic common feature library of the devices in their corresponding device logical groups; and a feature weighting module, configured to adjust the feature weight of the semantic common feature corresponding to the common word in the semantic common feature library of the device to which it belongs, based on the success rate corresponding to the use of the common word by the user and the successful execution of the corresponding control instructions.

[0109] Based on any embodiment of the device in this application, following the instruction application module 3300, the device further includes: a fingerprint generation module, configured to generate a unique group fingerprint based on the group common description data of the device group control request; an entry caching module, configured to associate the device list of the device logical group with the group fingerprint as a cache entry and store it in the cache; a cache retrieval module, configured to respond to a subsequently triggered device group control request, determine whether the group fingerprint generated by its group common description data hits the cache, and if it does, directly retrieve the device list of the hit cache entry as the device logical group; and a cache cleanup module, configured to automatically delete the cache entry corresponding to the device list in the cache when it detects that the devices in the device list or the semantic common features of the devices have changed.

[0110] Based on any embodiment of the device in this application, the instruction application module 3300 includes: a status determination module, configured to query and determine the real-time status of each device in the device logical group; a status detection module, configured to compare the expected result of the control instruction with the real-time status, and if the comparison result is consistent with the real-time status, cancel the issuance of the control instruction to that device; and an instruction issuance module, configured to continue issuing the control instruction to all devices in the device logical group if the comparison result is inconsistent with the real-time status.

[0111] To address the aforementioned technical problems, embodiments of this application also provide a computer device for implementing the intelligent central control device of this application. For example... Figure 3 The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, a network interface, and various communication components connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store control information sequences. When the computer-readable instructions are executed by the processor, they enable the processor to implement a device group control method. The processor of the computer device provides computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, they enable the processor to execute the device group control method of this application. The network interface of the computer device is used for communication with terminals. Those skilled in the art will understand that… Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0112] In this embodiment, the processor is used to execute... Figure 2 The system defines the specific functions of each module and its sub-modules. The memory stores the program code and various data required to execute these modules or sub-modules. The network interface is used for data transmission between user terminals and the server. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the device group control device of this application. The server can call the server's program code and data to execute the functions of all sub-modules.

[0113] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the device group control method of any embodiment of this application.

[0114] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0115] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those in the open-source operations, methods, and processes of this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0116] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for group control of equipment, characterized in that, include: Receive device group control requests and obtain common group description data and control commands to be executed. In response to the device group control request, devices whose semantic common features match the group common description data are retrieved from the device library to form a device logical group. The device library is configured with the semantic common features to which each device belongs in the private network to which the local device is connected. The control command is issued to all devices in the device logic group.

2. The equipment group control method according to claim 1, characterized in that, Devices whose semantic common features match the common description data of the group are retrieved from the device database, forming a logical device group, including: For each common word contained in the common description data of the group, calculate the semantic similarity between it and each semantic common feature of each device in the device library, and use it as the basic similarity score; For each device in the device library, all basic similarity scores corresponding to that device are weighted and fused to generate a candidate device score corresponding to the common description data of the group. Based on the candidate device scores of all devices, target devices are selected from the device library to form the device logical group corresponding to the device group control request.

3. The equipment group control method according to claim 2, characterized in that, For each device in the device library, a weighted fusion of all basic similarity scores corresponding to that device is performed, including: The common description data of the group is processed by the named entity recognition model to identify the entity words that constitute the common vocabulary and their corresponding entity types. Based on the preset relational data representing the mapping relationship between entity type and word weight, the word weight of each entity word is set according to the entity type to which each entity word belongs; the updated similarity score is obtained by multiplying each basic similarity score by the feature weight of the semantic common feature corresponding to the score and the word weight of the common word corresponding to the score. By merging all updated similarity scores for each device, a candidate device score is generated for that device.

4. The equipment group control method according to claim 3, characterized in that, By merging all updated similarity scores for each device, a candidate device score is generated for that device, including: Extract the data feature set of the entity type set obtained after named entity recognition, the data feature set including: whether there is a device type entity and whether there is a spatial location entity; The set of entity types obtained after named entity recognition is detected to determine the instruction pattern. If both location type entities and device type entities exist in the set, it is determined to be a precise multi-condition instruction pattern; otherwise, it is determined to be a fuzzy single-point instruction pattern. If the device is determined to be the precise multi-condition instruction mode, a weighted summation fusion strategy is adopted to accumulate all the updated similarity scores corresponding to the device to generate the device candidate score. If the device is determined to be in the fuzzy single-point instruction mode, a maximum value filtering and fusion strategy is adopted, and the maximum value among all updated similarity scores corresponding to the device is taken as the candidate score of the device.

5. The equipment group control method according to claim 2, characterized in that, After issuing the control command to all devices in the device logical group, the process includes: Acquire device group control requests and their application result data generated by the user's previous interactions. The application result data includes the result of whether the control command of the corresponding device group control request was successfully executed. The common description data of the group control requests of each device are segmented and statistically analyzed to extract common words that appear more frequently than a preset threshold. The extracted common words are used as semantic common features and added to the semantic common feature library of the devices in their corresponding device logical groups; Based on the success rate of common words being used by users and corresponding control commands being successfully executed, the feature weights of the semantic common features corresponding to the common words in the semantic common feature library of the device are adjusted.

6. The equipment group control method according to any one of claims 1 to 5, characterized in that, After issuing the control command to all devices in the device logical group, the process includes: A unique group fingerprint is generated based on the common group description data of the device group control request; The device list of the device logical group is associated with the group fingerprint and stored in the cache as a cache entry; In response to subsequent device group control requests, determine whether the group fingerprint generated by the common description data of the group hits the cache. If it does, directly call the device list of the hit cache entries as the device logical group. When a change is detected in the devices in the device list or in the semantic common features of the devices, the cache entry corresponding to the device list in the cache is automatically deleted.

7. The equipment group control method according to any one of claims 1 to 5, characterized in that, The control command is issued to all devices in the device logical group, including: Query to determine the real-time status of each device in the device logical group; The expected result of the control command is compared with the real-time state. If the comparison result is consistent with the real-time state, the control command is cancelled from being sent to the device. If the comparison result is inconsistent with the expected result and the real-time state, the control command will continue to be sent to all devices in the device logic group.

8. A group control device for equipment, characterized in that, include: The request receiving module is configured to receive group control requests from devices and obtain common group description data and control instructions to be executed. The instant assembly module is configured to respond to the device group control request by querying the device library for devices whose semantic common features match the group common description data to form a logical device group. The device library is configured with the semantic common features to which each device belongs in the private network to which the local device is connected. The instruction application module is configured to issue the control instructions to all devices in the device logical group.

9. An intelligent central control device, comprising a camera unit and a controller, the controller including a processor and a memory, the camera unit being used to acquire and preview video streams, characterized in that, The processor invokes and runs a computer program in the memory to perform the steps of the device group control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, performs the steps included in the corresponding method.

Images