Service control message transmission method and device, equipment and medium

Abstract

The invention relates to a service control message transmission method and device, equipment and a medium, and the method comprises the steps: obtaining a service control message generated in a smart home network, and determining a specified target service entity in the service control message; association state information and association control semantic information of a target node corresponding to the target service entity are determined from an equipment state tree, the equipment state tree comprises equipment nodes, logic nodes and space nodes, and the nodes form a hierarchical structure through a reference relationship; based on the association state information and the association control semantic information of the target node, determining controlled device nodes controlled by the target service entity in the device state tree, and generating device node messages with dynamic priorities corresponding to the controlled device nodes; and scheduling the equipment node message to a corresponding message processing queue for issuing according to the dynamic priority. According to the invention, the reliability of service control message transmission, the scheduling efficiency and the system usability can be obviously improved.

Description

Technical Field

[0001] This application relates to the field of smart homes, and more particularly to a method and apparatus for transmitting business control messages, as well as devices and media. Background Technology

[0002] In a smart home network environment, achieving efficient and reliable transmission of business control messages is crucial to ensuring the system's intelligence level. Traditional technologies typically use mechanisms based on simple event triggering or static rule mapping to process control commands. The underlying principle is to directly map user-initiated scene control requests, such as clicking a cinema mode button, into a set of fixed device control commands through predefined configurations, such as closing curtains, dimming lights, and turning on the projector, and then distribute these commands to the corresponding smart devices for execution.

[0003] However, traditional solutions based on static mapping reveal inherent technical limitations when faced with the complex heterogeneity of devices and the dynamically changing network and computing resource states in smart home scenarios. Firstly, traditional solutions lack the ability to perceive the overall network resource status. Their control logic is fixed during the configuration phase, failing to detect the real-time load, battery level, or network connectivity status of the target or associated devices at the moment of execution. This can lead to the system assigning computationally intensive rendering tasks to a media center already experiencing CPU overload, or sending frequent data acquisition commands to a mobile sensor with a nearly depleted battery. This can not only cause task failures or device downtime but also trigger a chain reaction of failures due to the depletion of critical device resources, severely impacting the overall stability of the smart home system and the reliability of control commands.

[0004] Secondly, traditional technologies lack differentiated priority processing mechanisms at the message scheduling level. The device control commands they generate are typically placed in a uniform queue and processed sequentially, or only have simple static priorities based on the control source type. This scheduling method fails to reflect the inherent differences in the urgency of different business control messages. For example, a device control sequence triggered by a security alarm and an ambient lighting adjustment request are treated the same in traditional technologies. When the load is high, critical security-related instructions may be queued instead of executed promptly, leading to response delays and failing to meet the time-sensitive control task requirements of smart home scenarios.

[0005] Furthermore, the inability to dynamically adjust the order and strategy of instruction distribution based on the real-time status of the device also leads to the inefficient use of system resources and a decline in the experience of high-priority tasks.

[0006] Therefore, under the current technological background, the business control message transmission method in smart home networks has obvious shortcomings in dealing with dynamic environments, ensuring the reliability of critical tasks, and improving system resource efficiency. This application aims to provide an improved solution for this purpose. Summary of the Invention

[0007] The primary objective of this application is to solve at least one of the aforementioned problems by providing a method, apparatus, device, and medium for transmitting business control messages.

[0008] To achieve the various objectives of this application, the following technical solution is adopted: A service control message transmission method provided for one of the purposes of this application includes the following steps: Obtain service control messages generated in the smart home network and identify the target service entity specified in the service control message; The associated status information and associated control semantic information of the target node corresponding to the target business entity are determined from the device status tree corresponding to the smart home network. The device status tree includes device nodes representing physical devices, logical nodes representing logical functions, and spatial nodes representing physical locations. The nodes form a hierarchical structure through reference relationships. Based on the associated status information and associated control semantic information of the target node, the controlled device nodes in the device status tree that are controlled by the target business entity are determined, and device node messages with dynamic priorities are generated for each controlled device node. Based on the dynamic priority, the device node messages are scheduled to the corresponding message processing queue for distribution.

[0009] A service control message transmission apparatus, proposed to meet one of the purposes of this application, includes: The entity determination module is configured to acquire service control messages generated in the smart home network and determine the target service entity specified in the service control message. The information determination module is configured to determine the associated status information and associated control semantic information of the target node corresponding to the target business entity from the device status tree corresponding to the smart home network. The device status tree includes device nodes representing physical devices, logical nodes representing logical functions, and spatial nodes representing physical locations. The nodes form a hierarchical structure through reference relationships. The message generation module is configured to determine the controlled device nodes in the device status tree controlled by the target business entity based on the associated status information and associated control semantic information of the target node, and generate device node messages with dynamic priorities for each controlled device node. The message scheduling module is configured to schedule the device node messages to the corresponding message processing queue for distribution based on the dynamic priority.

[0010] In another aspect, a computer device provided for one of the purposes of this application includes a controller, the controller including a processor and a memory, the processor invoking and running a computer program in the memory to perform the steps of the business control message transmission method.

[0011] On 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 business control message transmission method, which, when invoked by a computer, executes the steps included in the corresponding method.

[0012] This application achieves significant benefits in several aspects by constructing a complete technical solution from business intent parsing to intelligent scheduling of device commands. Specifically, by introducing a device state tree model and continuously querying the real-time status information of target nodes and related nodes during message transmission, the current load and health of devices can be accurately perceived before distributing control messages. This effectively avoids sending invalid commands to offline, overloaded, or faulty devices, thereby significantly improving the reliability of control message execution and system stability. Simultaneously, by dynamically calculating the priority of device node messages and performing differentiated scheduling accordingly, the inherent urgency differences of business processes can be automatically identified. The message processing order can be adjusted based on the real-time load of devices, ensuring that high-priority critical messages are processed quickly, optimizing resource allocation, and reducing the response time of core businesses. Furthermore, by encapsulating the complex state perception, message parsing, and scheduling logic into a coherent process, a simple interface is provided to the upper layer, reducing application development complexity and system maintenance costs, and improving the overall usability and maintainability of the smart home system. Attached Figure Description

[0013] 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 service control message transmission method of this application; Figure 2 This is a schematic block diagram of the service control message transmission device of this application; Figure 3 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0014] The technical solution of this application can be deployed in a typical smart home network environment. This environment typically includes a home gateway as the control hub, various smart terminal devices with heterogeneous computing capabilities, and a local area network connecting these devices. The home gateway can be responsible for running the computer program implemented according to the service control message transmission method of this application and interacting with cloud services. The smart terminal devices come in various forms, including but not limited to smart TVs, smart speakers, smart cameras, game consoles, and environmental sensors. These devices connect to the home network wirelessly or via wired connections and report their status and computing capabilities to the gateway.

[0015] This application's technical solution constructs and maintains a logical device state tree in a smart home network environment. This device state tree is typically built within a home gateway or dedicated control device, organized according to both physical space and functional logic dimensions, forming a hierarchical tree topology. The root node of this tree represents the entire smart home network. Multiple levels of intermediate nodes can be created below the root node. These nodes are usually arranged according to physical spatial location, such as including floors, rooms, etc., forming a relatively stable skeleton structure of the device state tree as its inherent topology. The leaf nodes of the device state tree directly correspond to specific physical devices in the network, thus forming device nodes. Each leaf node persistently records its corresponding device's unique identifier, static capability resource information, and dynamically updated real-time status information. Intermediate nodes are not directly bound to hardware; they are used to abstractly represent logical functional entities or spatial areas, such as logical groups like a cinema mode or a living room lighting group. Nodes form a hierarchy through parent-child reference relationships. Logical nodes establish dependencies with one or more device nodes through additional reference lists, thereby achieving flexible combinations of logical functions without changing the physical ownership of the devices.

[0016] The business control message transmission method described in this application is implemented by a computer program running on a home gateway or control center device, such as a smart central control device or a mobile terminal. This method implements the response and processing of node state changes and business messages in the device state tree. When a requesting device in the smart home network, such as a user's mobile application or an automation rule engine, initiates a business control message, the method of this application is triggered. The method first parses the message to determine the target business entity, then queries the device state tree to obtain the real-time state and control semantics of the target node, thereby determining the set of device nodes to be controlled and generating a device-level message with dynamic priority. Finally, the message is scheduled and sent according to the dynamic priority. Upper-layer applications receive processing result notifications through a subscription mechanism.

[0017] The upper-layer applications of this application, such as user-used mobile phones, applications on smart central control devices, or automated scene rule engines, submit business control messages and receive final calculation results by calling the programming interfaces provided in this application. The computer program in this application is responsible for listening to messages, maintaining the device state tree, and performing intelligent scheduling and message delivery. In this way, this application enables upper-layer applications to conveniently utilize the collaborative computing capabilities of the entire smart home network, significantly improving the local processing efficiency and system responsiveness of complex intelligent tasks.

[0018] Having clarified the aforementioned network architecture, core model, and basic processes, the following section will further elaborate on the implementation details of the technical solution of this application in conjunction with specific embodiments.

[0019] Please see Figure 1 In some embodiments, the service control message transmission method of this application can be implemented as an application program running in the processor of a computer device. The method includes: Step S3100: Obtain the service control message generated in the smart home network and determine the target service entity specified in the service control message; Business control messages can be sent by upper-layer applications or program modules such as automatic rule engines in a device in the smart home network. After the business control message is received, it is parsed to determine the target business entity that the message intends to act on. The target business entity can correspond to various types of nodes in the device state tree built by the smart home network.

[0020] Business control messages are instruction data generated within a smart home network that express high-level business intentions. In one embodiment, such messages are generated and sent by a requesting device in the network. The requesting device can be a smart terminal that the user interacts with directly, such as a home control application installed on a smartphone, a wall-mounted smart control screen, or a voice assistant interface. The requesting device can also be an automation logic engine running in the network, such as a rule engine that automatically triggers scenes based on time or sensor events. Business control messages can be sent via the home LAN or internal interface to a computer device running an application implemented according to the methods of this application, where they are received and processed by the application running the methods of this application.

[0021] In one embodiment, business control messages can be obtained by listening to specific network ports or message queues. For example, the application of this application can act as a persistent service, bound to a local TCP or UDP port, to receive data packets sent from requesting devices according to a predetermined protocol format. In another embodiment, the application of this application can obtain messages by subscribing to a centralized message bus system. When a new business control message is published to a specific topic on the bus, it receives a notification and retrieves the message content. This approach decouples message producers and consumers, improving scalability.

[0022] After successfully obtaining the service control message, it needs to be parsed to extract key information, the first step being to identify the target service entity specified in the message. The target service entity is the object identifier that the message will operate on within the smart home network. In one embodiment, the service control message can be encapsulated in a structured data format, such as JSON or XML, to facilitate machine parsing. The message body contains a field specifying the target service entity, the value of which is a unique identifier. For example, a service control message for activating cinema mode might contain the following in JSON format: {"target_entity": "scene_cinema_mode", "action": "activate", "parameters":{}}. The parsing process involves reading field values ​​like "target_entity" from the message body to determine that the target service entity is "scene_cinema_mode".

[0023] The identifier of the target service entity directly corresponds to the identifier of a node in the device state tree. In one embodiment, the target service entity may correspond to a logical node in the device state tree, such as a node representing a specific functional scenario, like cinema mode or home mode. In another embodiment, the target service entity may also correspond to a spatial node, such as a node representing a physical room, like the living room or master bedroom. Furthermore, the target service entity may also directly specify a device node for advanced control of a single device. This application focuses on the case where the target service entity is a logical node.

[0024] Step S3200: Determine the associated status information and associated control semantic information of the target node corresponding to the target business entity from the device status tree corresponding to the smart home network. The device status tree includes device nodes representing physical devices, logical nodes representing logical functions, and spatial nodes representing physical locations. The nodes form a hierarchical structure through reference relationships. After identifying the target business entity specified in the business control message, the associated state information and associated control semantic information of the target node corresponding to the target business entity are obtained from the device state tree corresponding to the smart home network. As revealed above, the device state tree, as a virtual mapping of the smart home network, forms a hierarchical structure through reference relationships between its nodes, including device nodes representing physical devices, logical nodes representing logical functions, and spatial nodes representing physical locations.

[0025] In one embodiment, the first step is to locate the node in the device state tree that precisely matches the target service entity identifier. This can be done by traversing the node index table of the device state tree, comparing the target service entity identifier parsed from the service control message, such as scene_cinema_mode, with the node identifiers stored in the index table. When a node with a completely matching identifier is found, that node is officially identified as the target node for this round of processing.

[0026] After locating the target node, its associated status information needs to be obtained. This associated status information is crucial for assessing the current availability and health of the target node and its associated nodes. In one embodiment, when the target node is a logical node, obtaining its associated status information includes two parts. One part is the status information recorded by the logical node itself, such as the global enable status of the logical scenario, and the success or failure record of the most recent execution. The other part, and more importantly, is the real-time status information of each device node associated with the logical node through reference relationships. Specifically, it is necessary to read the reference list maintained by the target logical node from its data structure. This list contains the identifiers of all device nodes that the implementation of this logical function depends on. Subsequently, based on these device node identifiers, the corresponding device node is located one by one in the device status tree, and its current status information is read. This status information includes, but is not limited to, the current active status of the device, such as online or offline, and health indicators, such as CPU load rate, remaining memory, and network connection strength. Combining the logical node's own status information with the real-time status of all the device nodes it references constitutes the complete associated status information for subsequent decision-making.

[0027] In another embodiment, if the target node is a device node, its associated status information mainly includes the real-time status information of the device node itself. If the target node is a spatial node, its associated status information may need to aggregate the status information of all its subordinate sub-device nodes and sub-logical nodes, for example, by calculating the proportion of online devices or a comprehensive health score to characterize the overall status of the spatial area.

[0028] Simultaneously, it is necessary to obtain the pre-configured associated control semantic information in the target node. This associated control semantic information defines the logical rules for converting business control messages for that target node into specific device-level control actions. In one embodiment, the associated control semantic information can be represented as an executable script or a structured mapping rule table. For example, for a cinema mode logic node, its associated control semantic information might explicitly stipulate that when a business action of "activate" is received, a device control command to adjust the brightness to 50% should be sent to the referenced lighting device node, a "close" command should be sent to the referenced curtain device node, and an "open" command should be sent to the referenced projector device node. This rule details the conversion relationship from business intent to device instructions and is the direct basis for generating device-level control messages.

[0029] The way to obtain association control semantic information can be by loading it from the configuration file associated with the target node, or by directly reading the rule definition stored in a specific field of the node data structure.

[0030] Step S3300: Based on the associated status information and associated control semantic information of the target node, determine the controlled device nodes in the device status tree that are controlled by the target business entity, and generate device node messages with dynamic priorities for each controlled device node. After successfully acquiring the associated status information and associated control semantic information of the target node, based on the acquired information, the set of controlled device nodes that need to be controlled is further defined, and a control message with an intelligent priority tag is generated for each node.

[0031] In one embodiment, determining the set of controlled device nodes may depend on the type of the target node and its associated control semantic information. When the target node is a logical node, the controlled device nodes are all the device nodes associated with that logical node through its reference list. For example, for a cinema mode logical node, the reference list defined in its associated control semantic information includes identifiers of device nodes such as smart lights, electric curtains, and projectors; these device nodes together constitute the set of controlled device nodes. The preset mapping rules in the associated control semantic information, such as response rules for activating business actions, explicitly specify the need to operate these device nodes. If the associated status information shows that a referenced device node is offline or faulty, one approach is to still include it in the set of controlled device nodes, but mark its status as abnormal in its corresponding device node message, with subsequent steps determining whether to skip execution or attempt a retry. Another approach is to directly filter based on the associated status information at this stage, removing device nodes that do not meet the basic online and health requirements from the set of controlled device nodes for this execution to ensure the validity of the instruction.

[0032] After determining the set of controlled device nodes, a corresponding device node message is generated for each node in the set. In one embodiment, the associated control semantic information is parsed according to a predefined mapping rule for the target node. This rule clarifies how to transform high-level business actions in the business control message into specific device-level control commands for the corresponding controlled device node. For example, for a cinema mode logic node, its associated control semantic information specifies that the activation action is mapped as follows: sending a command to the lighting device node to set the brightness to 30%, sending a shutdown command to the curtain device node, and sending an on command to the projector device node. The parsing process is to convert the received business actions into a series of explicit device-level control commands with target device identifiers, according to this rule.

[0033] Subsequently, a corresponding device node message is created for each parsed device-level control command. In one embodiment, the device node message is implemented as a structured data object containing several key fields, such as: a target controlled device node identifier field, used to specify the receiving device of the message; a device-level control command field, carrying the specific control instruction after parsing; and a priority field, which can initially be empty or preset with a default value, to be filled with a dynamically calculated priority score later. This message structure encapsulates the control instruction, target device, and scheduling priority information together, providing a foundation for subsequent differentiated scheduling.

[0034] Device node messages need to be assigned a dynamic priority. In this application, the dynamic priority can employ multi-factor decision-making, and its inputs may include the associated status information of the target node, the preset scenario level of the business control message, and the real-time load status of the controlled device node. In one embodiment, the dynamic priority score is derived through a weighted calculation model. This model comprehensively considers the scenario criticality factor reflecting the importance of the business, the message urgency factor reflecting the urgency of the task, and the device availability factor reflecting the current processing capacity of the device. For example, for a business control message triggered by a security alarm, its preset scenario level is usually high, contributing a high message urgency factor; if the current CPU load of the camera device node associated with the target node is low, it contributes a high device availability factor; the dynamic priority score calculated by combining these factors will be high, ensuring that the alarm message is processed first. After the calculation is completed, the obtained dynamic priority score is filled into the priority field of the corresponding device node message, thereby completing the final generation of device node messages with dynamic priorities.

[0035] Step S3400: According to the dynamic priority, schedule the device node message to the corresponding message processing queue for distribution.

[0036] After successfully generating a series of device node messages with dynamic priorities, each message can be intelligently assigned to a corresponding message processing queue based on its dynamic priority score, and then reliably sent to the target device for execution, thereby transforming the calculation decisions of the preceding steps into actual device control actions.

[0037] In one embodiment, this scheduling and delivery function can be implemented by pre-establishing and maintaining a set of mutually exclusive message processing queues with priority intervals. Each message processing queue is associated with a specific dynamic priority score range; for example, three queues can be set. The number of queues and interval boundaries can be flexibly configured according to actual business needs. When a new device node message is generated, the scheduler reads the dynamic priority score in its priority field, determines the interval range to which the score belongs based on the preset priority interval mapping rules, and then adds the message to the tail of the message processing queue bound to the corresponding interval. This priority interval-based queue allocation mechanism physically or logically isolates messages with different urgency levels.

[0038] In another embodiment, an absolute priority queue approach can be used, where a separate queue is maintained for each possible priority score or a very small score range. This approach provides the finest scheduling granularity but incurs significant management overhead. In contrast, the interval-based queue approach achieves a good balance between complexity and performance while maintaining scheduling effectiveness.

[0039] After messages are correctly assigned to queues, the message scheduler is responsible for retrieving messages from each queue and distributing them. A typical scheduling strategy is priority-weighted round-robin. The message scheduler runs as a separate daemon process or thread, checking each queue in descending order of priority. The scheduler first checks the high-priority queues. If the queue is not empty, it retrieves a device node message from its head for processing. After processing, instead of continuously emptying the queue, it immediately moves on to checking the next highest priority queue, processing one message in the same way. This cycle continues until the lowest priority queues have been checked, and then a new round of polling begins again from the highest priority queue. This strategy ensures that messages in high-priority queues always receive more frequent processing opportunities, thus enjoying lower latency, while preventing messages in low-priority queues from being completely starved.

[0040] After retrieving the device node message from the queue, the final delivery operation is performed. In one embodiment, the delivery process includes a message scheduler parsing the content of the device node message to obtain the network identifier (such as IP address, device ID) of the target controlled device node and the device-level control command to be executed. Subsequently, the scheduler encapsulates the control command into a data packet of a specific format and sends it to the target device through the communication protocol used by the smart home network, such as HTTP RESTful API, MQTT message publishing, or CoAP. In one embodiment, the delivery can be asynchronous; the scheduler does not wait for a device response after sending a message but immediately continues processing the next message to maximize throughput. For critical instructions that require confirmation, a protocol with an acknowledgment mechanism can be used, and retry logic can be triggered if no confirmation is received within a certain time to ensure reliable delivery of instructions.

[0041] Furthermore, the entire scheduling and delivery process can be resiliently fault-tolerant. In one embodiment, when the message delivery to a device node fails more than a preset number of times consecutively, the scheduler can mark the device node as potentially faulty and suspend the delivery of subsequent messages to it, while simultaneously sending an alarm to the system monitoring module. On the other hand, the scheduler itself can monitor the length of each message queue. When it detects a serious backlog in a certain priority queue, it can dynamically adjust the polling weights and temporarily increase the access frequency to that queue to prevent queue overflow, achieving simple load awareness and adaptive adjustment.

[0042] It is easy to see from the above embodiments that this application has many technical advantages over traditional technologies, including but not limited to: First, this application significantly improves the adaptability and reliability of business control message processing in smart home systems. Traditional technologies cannot cope with dynamic environments due to a lack of awareness of the real-time status of smart devices in the smart home network. This application, by using a device state tree to continuously query and reference the real-time status information of the target node and its associated nodes during transmission, can accurately perceive the current load, health, and availability of network devices before distributing control messages. This effectively avoids sending invalid instructions to offline, overloaded, or faulty devices, thereby greatly improving the reliability and success rate of control message execution and enhancing the stability and resilience of the entire smart home system in the face of device status fluctuations.

[0043] Secondly, this application achieves intelligent optimization of the transmission efficiency of business control messages. Traditional, indiscriminate message scheduling mechanisms struggle to guarantee the timeliness of critical tasks. This application fundamentally solves this problem by dynamically calculating the priority of messages for each device node and performing differentiated scheduling based on this priority. This application can automatically identify the inherent differences in urgency among business control messages and dynamically adjust the order of messages in the processing queue based on the real-time load of the devices. This allows high-priority critical control messages, such as security alarm linkage commands, to be processed quickly before low-priority atmosphere adjustment commands, significantly reducing the response time of core services, optimizing system resource allocation, and ensuring the service quality and user experience of critical services under high system load.

[0044] Furthermore, this application enhances the overall usability and maintainability of smart home systems through its high level of integration and automation. It encapsulates complex device status awareness, message parsing and adaptation, and intelligent scheduling logic into a coherent process, presenting a simple business control message interface to upper-layer application developers or users. Users do not need to concern themselves with the specific devices involved at the underlying level or how they are scheduled; they only need to initiate high-level business requests to automatically, reliably, and efficiently complete all subsequent complex processing. This reduces the development complexity of downstream applications, simplifies the operation and maintenance management of smart home systems, and provides a solid technical foundation for building a more intelligent and autonomous home environment.

[0045] Based on any embodiment of the method in this application, the state information and associated control semantic information of the target node corresponding to the target service entity are determined from the device state tree corresponding to the smart home network, including: Step S3210: In the device status tree, query the node that matches the entity identifier of the target business entity, and determine the node as the target node; Based on the entity identifier in the service control message, a node matching the entity identifier of the target service entity can be directly queried in the device state tree, and that node is identified as the target node. The device state tree, as a virtual mapping of the smart home network, maintains index information for all nodes. The query operation can be quickly completed by traversing the node registry or hash index of the device state tree. Specifically, the target service entity identifier parsed from the service control message, such as the logical node identifier `scene_cinema_mode` representing cinema mode, is precisely matched with the node identifiers stored in the index. When a node with a completely matching identifier is found, that node is officially identified as the target node for this round of processing.

[0046] Step S3220: When the target node is a logical node, obtain the reference list set in the logical node from the device state tree to determine the various device nodes referenced by the target node; After successfully locating the target node, a corresponding information acquisition strategy is adopted based on the node type of the target node. In this embodiment, when the target node is a logical node, the reference list set in the logical node is obtained from the device state tree to determine the various device nodes referenced by the target node. The role of the logical node itself is abstraction and aggregation; it does not directly correspond to physical hardware, but rather establishes logical control relationships with one or more device nodes through a predefined reference list. This reference list is stored in the logical node's data structure, such as an array or list containing device node identifiers. After obtaining this list, all the specific physical devices on which this logical function depends can be clearly identified. For example, the cinema mode logical node may reference device nodes with identifiers such as light_living_room, curtain_living_room, and projector_living_room. These referenced device nodes are the direct objects for subsequently generating device-level control commands.

[0047] Step S3230: Obtain the self-state information recorded in the target node and the self-state information of each referenced device node to form associated state information. The self-state information includes one or more of the current active status and health indicators of the corresponding node. Next, it is necessary to obtain the relevant data that constitutes the associated state information. To this end, the associated state information is formed by obtaining the self-state information recorded in the target node and the self-state information of each referenced device node. The associated state information is a comprehensive view for assessing the current health and availability of the target node and its associated resources. For target nodes such as logical nodes, their associated state information consists of two parts. The first part is the state information recorded by the target logical node itself, such as the global enable status of the logical scenario, the success or failure record of the most recent execution, and other metadata. The second part, which is more dynamic, is the real-time self-state information of each device node in its reference list. This requires querying the device state tree again using the device node identifier to obtain the latest state snapshot of each referenced device node.

[0048] A node's own status information can include its current activity status, such as online or offline, as well as health indicators, such as current CPU load, remaining memory capacity, battery percentage, and network connection signal strength. These can be set and retrieved as needed. Aggregating the logical node's own status information with the real-time status information of all its referenced devices forms comprehensive associated status information, providing a crucial basis for determining whether the current logical scenario is suitable for execution.

[0049] Step S3240: Obtain the pre-configured associated control semantic information in the target node. The associated control semantic information includes mapping rules that map service actions in service control messages for the target node to one or more device-level control actions.

[0050] Simultaneously, it's necessary to obtain the pre-configured associated control semantic information from the target node. The specific methods for obtaining this information can vary. One approach is to load it from the configuration file associated with the target node. For example, each logical node can have an independent configuration file that stores its associated control semantic information in formats such as JSON or XML. After identifying the target node, the corresponding configuration file is searched and read from a pre-defined configuration directory or configuration service based on the node's unique identifier, and then the mapping rules are parsed out. Another approach is to directly embed the associated control semantic information into the target node's data structure within the device state tree, storing it as an attribute field of the node. This method reduces external dependencies and improves access efficiency.

[0051] Association control semantic information defines the conversion rules for transforming business control messages aimed at a target node into specific device-level control actions. Association control semantic information can be represented as a structured mapping rule table or an executable script logic. For example, for a cinema mode logic node, its association control semantic information might explicitly stipulate that when the business action in the business control message is activated, a command to set the brightness to 30% should be sent to the referenced lighting device node, a shutdown command should be sent to the referenced curtain device node, and an on command should be sent to the referenced projector device node. The mapping rules represented by the association control semantic information detail the mapping relationship from business intent to device commands, serving as a blueprint for driving device collaboration.

[0052] More specifically, the mapping rules in the associated control semantic information need to explicitly specify three elements: the service action, the target device node identifier, and the device-level control command to be sent. For example, a complete mapping rule can be expressed as: if the service action is active, send the command `set_brightness 30` to device node `light_1`. A rule can contain multiple such instructions, forming an instruction set to support complex scene control. Mapping rules can also support parameterization; for example, a service control message might carry the parameter brightness level 50, and the mapping rule could be defined as sending the command `set_brightness ${50}` to device node `light_1`, thus making the control behavior more flexible.

[0053] In one embodiment, in addition to basic action mapping, the associated control semantic information can also include execution condition constraints. For example, the mapping rule can be defined to execute only when the target node and its referencing device nodes are both online and their health is above a certain threshold. In another embodiment, exception handling rules can be defined, such as whether to retry, skip, or trigger an alternative action when sending a command to a device node fails. These advanced rules further enhance the intelligence and reliability of the control.

[0054] In another embodiment, if the target node is a device node, its associated state information mainly includes the state information of the device node itself, and its associated control semantic information may be directly defined as a mapping of standard control commands for the device. If the target node is a space node, its associated state information may need to aggregate the states of all its subordinate child nodes, and its associated control semantic information may be defined as batch operation rules for devices within the space.

[0055] The embodiments described above first locate the target node quickly through precise matching, then intelligently obtain the list of device nodes referenced by the node based on the node type, and then form a comprehensive health view by comprehensively considering the real-time status of the target node itself and its associated devices. Finally, predefined business-to-device control mapping rules are loaded. Thus, before distributing control commands, it is not only clear which devices need to be controlled, but also accurately grasps the current availability status of these devices and the specific control logic. This provides sufficient and accurate decision-making basis for generating intelligent, reliable, and dynamically prioritized device-level messages, avoiding the risk of sending invalid commands to unhealthy devices from the source, while ensuring that business intentions can be accurately translated into device actions, significantly improving the reliability and intelligence level of the entire control process.

[0056] Based on any embodiment of the method in this application, and based on the associated state information and associated control semantic information of the target node, the controlled device nodes in the device state tree controlled by the target business entity are determined, and device node messages with dynamic priorities are generated for each controlled device node, including: Step S3310: Based on the mapping rules between business actions and device control actions defined in the associated control semantic information of the target node, parse the business actions contained in the received business control message into device-level control commands for each determined controlled device node. In this embodiment, the high-level business actions contained in the received business control messages need to be converted into low-level control commands for each specific controlled device. This conversion process strictly follows the predefined mapping rules in the associated control semantic information obtained from the target node. These mapping rules explicitly specify a series of device-level operations to be performed for a specific business action. For example, if the business action of the business control message is activation, and the target node is a cinema mode logic node, the mapping rules defined in its associated control semantic information can explicitly require: sending a command to set the brightness to 50% to the referenced lighting device node, sending a shutdown command to the referenced curtain device node, and sending an on command to the referenced projector device node. The parsing process decomposes the abstract activation action into a set of explicit, specific instructions with target device identifiers and device-level control command parameters according to this rule.

[0057] Step S3320: For each parsed device-level control command, create a corresponding device node message. The device node message contains the identifier of the target controlled device node, the device-level control command, and a priority field. Next, a corresponding structured message unit, or device node message, is created for each parsed device-level control command. This message, as a complete data carrier, contains multiple fields. The target controlled device node identifier field uniquely identifies the receiving device, the device-level control command field carries the parsed specific operation instructions, and the message also includes a priority field. This field is initialized to empty or a default placeholder upon creation, with its value to be dynamically calculated and filled later. This message structure ensures that each instruction is tightly bound to its target device and future scheduling priority.

[0058] Step S3330: Based on one or more of the following data: the associated status information of the target node, the preset scenario level of the service control message, and the real-time load status of the controlled device node, determine the dynamic priority score of each device node message. Subsequently, a dynamic priority score can be calculated for each device node message according to preset business logic. This score serves as a comprehensive evaluation result, and its calculation model can consider input data from multiple dimensions. In one embodiment, the data used for calculation includes the scene criticality reflected by the associated status information of the target node, the task urgency reflected by the preset scene level in the business control message, and the device availability represented by the current real-time load status of the controlled device node. For example, a business control message triggered by a security alarm typically has a high preset scene level, indicating a high urgency factor; if the CPU load of the camera device associated with its target node is currently very low, it indicates a high device availability factor; the dynamic priority score calculated by combining these factors will be significantly improved, ensuring that security-related instructions are processed with priority. Conversely, even if the preset scene level of the corresponding target node is high, the dynamic priority score of the corresponding device node message may be reduced due to the influence of associated status information and real-time load status. The specific calculation of the dynamic priority score can adopt a weighted scoring model, assigning weights to different factors and summing them to quantify their comprehensive urgency.

[0059] Step S3340: Assign the dynamic priority score to the priority field of the corresponding device node message to complete the generation of device node messages with dynamic priority.

[0060] Finally, the calculated dynamic priority score is assigned to the priority field of the corresponding device node message, thus completing the final assembly of the device node message and upgrading it from a simple instruction carrier into a task unit with intelligent scheduling attributes and a clear priority. Afterward, this complete message, containing the target device, control command, and dynamic priority, can enter the subsequent scheduling queue, awaiting dispatch.

[0061] The embodiments described above first decompose high-level business intents into specific device-level control commands based on predefined semantic rules. Then, each command is encapsulated into a standardized message unit containing a target device identifier and control instructions, with a priority field reserved. Subsequently, the priority score of each message is dynamically calculated based on multi-dimensional data such as the criticality of the business scenario, the urgency of the task, and the real-time availability of the device. Finally, this score is assigned to the corresponding message to complete the final assembly. As a result, each generated device-level control message not only carries clear operation instructions but also embeds intelligent tags reflecting its current processing urgency. This provides a precise basis for subsequent differentiated and efficient scheduling. From the source of message generation, it ensures that high-value tasks can be identified and processed first, significantly improving the intelligence level of system resource allocation and the response time of critical businesses.

[0062] Based on any embodiment of the method in this application, a dynamic priority score for each device node message is determined based on one or more of the following data: the association status information of the target node, the preset scenario level of the service control message, and the real-time load status of the controlled device node. This includes: Step S3331: Extract the scenario criticality factor from the associated status information of the target node, extract the message urgency factor from the preset scenario level of the business control message, and extract the device availability factor from the real-time load status of the controlled device node. Before calculating the dynamic priority score, key factors for quantitative evaluation need to be extracted from the available data sources. This step is responsible for extracting standardized numerical indicators from the raw data, laying the foundation for subsequent weighted calculations.

[0063] First, a scene criticality factor is extracted from the associated state information of the target node. This factor quantifies the inherent importance or criticality of the target business scenario within the smart home system. The associated state information may contain direct or indirect indicators characterizing scene criticality. In one embodiment, the scene criticality factor can be directly mapped to a predefined attribute value of the target node. For example, in the device state tree, a logical node representing a security arming scenario can be pre-assigned a higher criticality level, such as a value of 90, while a scene node representing atmosphere adjustment is assigned a lower criticality level, such as a value of 30. In another embodiment, the scene criticality factor can be indirectly calculated by analyzing historical execution data in the associated state information, for example, by comprehensively scoring the scenario based on its historical trigger frequency, success rate, and impact on system security or user experience. The scene criticality factor is a relatively static but important indicator that ensures critical business functions receive due attention in priority assessment.

[0064] Secondly, the message urgency factor is extracted from the preset scenario levels of the business control message. This factor directly reflects the urgency of the task represented by the current business control message. The preset scenario level is an initial attribute assigned by the initiator when the business control message is created, usually existing in the form of a numerical value or a level label. The extraction process is to map this attribute to a standardized numerical value. For example, if the preset scenario level uses three levels—high, medium, and low—it can be mapped to values ​​of 80, 50, and 20, respectively. If a numerical range of 1-10 is used, it can be used directly or scaled proportionally. The message urgency factor reflects the immediate priority of this specific task request. For example, an emergency message triggered by a smoke alarm will inevitably have a much higher urgency factor than a message about timed light adjustment. This factor ensures that high-urgency tasks receive priority processing.

[0065] Finally, a device availability factor is extracted from the real-time load status of the controlled device nodes. This factor characterizes the current capacity margin of the target controlled device node to execute new tasks. The device availability factor is negatively correlated with the real-time load status of the device; that is, the higher the load, the lower the availability. Extraction requires reading the real-time resource status information of the controlled device nodes, including but not limited to current CPU utilization, remaining memory capacity, and current network interface throughput. In one embodiment, the device availability factor can be calculated as a comprehensive score; for example, the availability factor equals 100 minus the weighted value of CPU utilization. In another embodiment, judgment can be based on thresholds for multiple resource dimensions. If the utilization of all critical resources is below a safety threshold, a high availability factor is assigned; if any resource exceeds the threshold, its availability factor is significantly reduced. The device availability factor introduces dynamic considerations of the system's real-time status, avoiding the distribution of new tasks to overloaded devices, thereby ensuring the success rate of task execution and device stability.

[0066] Through the extraction process described above, raw state data from different sources and with different dimensions are transformed into three standardized and comparable numerical factors: scenario criticality factor, message urgency factor, and device availability factor. These factors together constitute the input vector for dynamic priority score calculation, enabling subsequent weighted decision-making to be carried out within a unified mathematical framework.

[0067] Step S3332: Assign preset weight coefficients to the scenario criticality factor, message urgency factor and device availability factor respectively, wherein the weight coefficient of the message urgency factor is configured to be higher than the weight coefficient of the device availability factor. After successfully extracting the scenario criticality factor, message urgency factor, and device availability factor, appropriate weight coefficients need to be assigned to these factors to reflect their relative importance in the final priority decision. The allocation of weight coefficients directly reflects the system's scheduling strategy bias. In one embodiment, the weight coefficients can be statically configured in advance by the system administrator according to the business strategy. In another embodiment, the weight coefficients can also be dynamically adjusted based on historical execution results or the current overall system load.

[0068] The weighting design follows the principle of ensuring that the message urgency factor dominates the decision-making process. Therefore, the weight coefficient of the message urgency factor is explicitly configured to be higher than that of the device availability factor. This configuration reflects the design philosophy that prioritizes responding to immediate business needs over local load balancing. For example, a feasible weighting scheme is to set the weight coefficient of the message urgency factor to 0.5, the weight coefficient of the scenario criticality factor to 0.3, and the weight coefficient of the device availability factor to 0.2. This setting means that even if a target device node has a high current load, as long as the business control message itself is very urgent, its calculated dynamic priority score will still remain at a high level, thus ensuring that critical tasks can be prioritized. This strategy effectively prevents delays in processing high-urgency messages due to an excessive pursuit of load balancing.

[0069] Step S3333: Based on each of the factors and their corresponding weight coefficients, determine the dynamic priority score of the device node message corresponding to the controlled device node.

[0070] After determining the weight coefficients of each factor, the dynamic priority score of the device node message corresponding to the controlled device node can be calculated based on each factor and its corresponding weight coefficient. One of the most direct and effective implementations is to use a weighted summation model. This model multiplies each factor by its corresponding weight coefficient and then sums all the products to obtain the final dynamic priority score. This can be expressed as: Dynamic Priority Score = Scenario Criticality Factor × W_scene + Message Urgency Factor × W_urgency + Device Availability Factor × W_availability, where W_scene, W_urgency, and W_availability are the weight coefficients of the corresponding factors, and W_urgency > W_availability.

[0071] In another embodiment, the calculation process can incorporate nonlinear functions to handle specific situations. For example, a threshold can be set for the device availability factor. When the device availability factor falls below a certain critical value, indicating that the device is extremely busy, its weight coefficient can be significantly reduced, or even its contribution can be set to zero, to avoid assigning urgent tasks to a device that is almost unresponsive. Another embodiment can consider the interaction between factors. For example, when both the message urgency factor and the scenario criticality factor are high, their combined contribution can be appropriately amplified to highlight extremely high-priority tasks.

[0072] The calculated dynamic priority score is a quantified value that comprehensively reflects the importance and urgency of the current task, as well as the execution capability of the target device. This score will serve as the basis for scheduling device node messages.

[0073] The embodiments described above first extract key quantitative factors representing business importance, task urgency, and equipment availability from multi-source heterogeneous data in a standardized manner. Then, through a preset weighting coefficient strategy, the message urgency factor is explicitly assigned a higher decision weight than the equipment availability factor, ensuring that immediate business response takes precedence over local load balancing. Finally, a mathematical model such as weighted summation is used to integrate each factor and its weight into a single score output. This makes the message priority of each device node no longer dependent on a single dimension or static configuration, but dynamically generated based on a comprehensive consideration of business intent, real-time task characteristics, and system resource status. This achieves a leap from simple sorting to intelligent trade-offs in scheduling decisions, significantly improving the ability to distinguish the urgency of tasks and optimize resource allocation in complex and dynamic environments.

[0074] Based on any embodiment of the method in this application, the dynamic priority score of the device node message corresponding to the corresponding controlled device node is determined based on each of the factors and their corresponding weight coefficients, including: Step S333a: Perform a weighted summation based on each factor and its corresponding weight coefficient, and use the summation result as the initial priority score; The previous embodiment has already revealed the specific implementation of weighted summation based on each factor and its corresponding weight system, which will not be repeated here for the sake of brevity. It should be understood that in this embodiment, the score determined by the weighted summation is regarded as the initial priority score, rather than the final dynamic priority score.

[0075] Step S333b: Based on the position of the controlled device node in the network topology of the smart home network and the hop distance between the controlling device that submitted the service control message, determine the communication overhead adjustment value, wherein the communication overhead adjustment value is positively correlated with the hop distance; After each device node message determines its initial priority score, this embodiment further introduces network topology considerations to optimize scheduling decisions more finely.

[0076] The communication overhead adjustment value can be determined based on the hop count distance between the controlled device node and the controlling device submitting the service control message in the network topology of the smart home network. Hop count distance refers to the number of intermediate routing devices or gateways a data packet must traverse from the controlling device to the controlled device node. In one embodiment, the topology information of the smart home network can be pre-obtained via a network discovery protocol and stored in a device state tree or a dedicated network topology graph. Each device node records the parent node or gateway information it traverses to connect to the network. By traversing the connection relationships between device nodes, the number of hops along the path from the controlling device to the controlled device node can be calculated. For example, if the controlling device is a user's mobile phone and the controlled device is a smart light in the living room, and the data needs to pass through the home wireless router before reaching the smart light, then the hop count distance is 2.

[0077] The communication overhead adjustment value is positively correlated with the hop count distance. This means that the more hops there are, the larger the adjustment value, indicating a longer transmission path and higher communication overhead. In one embodiment, the communication overhead adjustment value can be designed as a linear function of the hop count distance; for example, the communication overhead adjustment value is equal to the hop count distance multiplied by a preset coefficient. In another embodiment, a lookup table method can be used to preset different adjustment values ​​for different hop count ranges; for example, the adjustment value is 5 when the hop count is 1, 10 when the hop count is 2, and 15 when the hop count is greater than or equal to 3. This positive correlation reflects the basic characteristics of network transmission: an increase in the hop count usually leads to increased latency, a potential decrease in reliability, and increased bandwidth consumption.

[0078] Step S333c: Subtract the initial priority score of the controlled device node from the communication overhead adjustment value to obtain the final dynamic priority score, wherein the communication overhead adjustment value is used as a negative adjustment item.

[0079] After obtaining the initial priority score and communication overhead adjustment value of the controlled device node, the two need to be combined to generate the final dynamic priority score. This is achieved through a subtraction operation: subtracting the communication overhead adjustment value from the initial priority score. The result is the final dynamic priority score of the device node's message. In this calculation model, the communication overhead adjustment value is explicitly used as a negative adjustment term.

[0080] The physical meaning of this calculation method lies in treating network transmission costs as a price or cost incurred in executing a task. The initial priority score reflects the inherent priority of the task calculated based on business importance, task urgency, and device availability. However, in actual execution, transmitting control commands to the target device itself also consumes network resources and introduces latency. The communication overhead adjustment value quantifies this transmission cost. By subtracting the communication overhead adjustment value from the initial priority score, it is equivalent to deducting the network transmission cost required to execute the task from the task's inherent priority. This ensures that the final priority considers not only the value of the task itself but also the communication efficiency of executing the task.

[0081] The design of using communication overhead as a negative adjustment term reflects a global perspective on system optimization. It allows for prioritizing devices with better network paths to handle tasks when business factors are similar. For example, suppose there are two smart lights with identical functions, one two hops away from the controller and the other one hop away. Their initial priority scores might be the same. However, the light two hops away has a larger communication overhead adjustment value, resulting in a lower final dynamic priority score. The scheduler will prioritize assigning tasks to the light one hop away, thereby reducing network congestion and transmission latency, and improving overall efficiency. This mechanism encourages assigning tasks to devices closer in the network topology, achieving localized optimization of network traffic.

[0082] The final calculated dynamic priority score is a quantitative indicator that integrates business requirements, device status, and network overhead. This score will be assigned to the priority field of the corresponding device node message, completing the final generation of a device node message with dynamic priority. Afterward, this message can enter the message processing queue and participate in scheduling contention based on its final dynamic priority score.

[0083] As can be seen from the above embodiments, by introducing communication overhead as a negative adjustment term, this application makes priority decision-making more refined, and optimizes the utilization efficiency of network resources while ensuring critical business operations.

[0084] Based on any embodiment of the method in this application, scheduling the device node message to the corresponding message processing queue for delivery according to the dynamic priority includes: Step S3410: Determine the priority range to which the device node message belongs based on the dynamic priority score carried in the device node message, and allocate the device node message to the message processing queue corresponding to the corresponding priority range. To implement message scheduling, each device node message is assigned to a corresponding message processing queue based on its dynamic priority score. To achieve priority-based differentiated processing, a set of priority ranges needs to be predefined, and an independent message processing queue needs to be maintained for each range. For example, three priority ranges can be defined: a high-priority range corresponding to scores of 80 to 100, a medium-priority range corresponding to scores of 50 to 79, and a low-priority range corresponding to scores of 0 to 49. The range boundaries and the number of queues can be configured according to actual needs. When a new device node message is generated, the scheduler reads its dynamic priority score, determines the range to which the score belongs according to the preset range mapping rules, and then adds the message to the tail of the message processing queue bound to the corresponding range. Step S3420: Following the order of priority ranges belonging to each message processing queue from high to low, the device node messages within each message processing queue are checked and dequeued in a loop. After messages are correctly distributed to their respective queues, the message scheduler is responsible for retrieving messages from the queues and preparing them for delivery. A typical scheduling strategy is priority-weighted round-robin scheduling. The message scheduler runs as an independent service process or thread, checking each queue in descending order of priority. The scheduler first checks the high-priority queues; if the queue is not empty, it retrieves a device node message from its head for processing. After processing this message, the scheduler does not continue processing the next message in the same queue, but immediately moves on to check the next highest priority queue, processing the message at its head as well. This continues until the lowest priority queues are checked, and then a new round of round-robin checks begins again from the highest priority queue. This strategy ensures that messages in high-priority queues always receive more frequent processing opportunities, thus enjoying lower latency, while preventing messages in low-priority queues from being completely starved.

[0085] In another embodiment, the scheduling strategy can be designed as strict priority scheduling, meaning that as long as there are messages in a high-priority queue, that queue is continuously processed until it is empty, and then the next priority queue is processed. This approach can maximize the real-time performance of high-priority tasks, but may cause low-priority tasks to remain unprocessed for extended periods. A weighted round-robin strategy achieves a better trade-off between fairness and efficiency.

[0086] Step S3430: In response to the dequeue event of the device node message, retrieve the device node message from the message processing queue, and send the device node message to the target controlled device node specified in the message for execution through the smart home network.

[0087] Once a device node message is dequeued, message delivery is triggered. In response to the dequeue event, the scheduler retrieves the device node message from the message processing queue and parses its content. The parsing operation includes obtaining the network identifier of the target controlled device node and the device-level control command to be executed. Subsequently, the scheduler delivers the control command to the target device using the communication protocol employed by the smart home network. In one embodiment, the delivery process can utilize lightweight protocols such as HTTP RESTful API, MQTT publish / subscribe pattern, or CoAP. For example, the scheduler can construct a JSON-formatted data packet containing command parameters and send it to the target device's IP address and specific port via an HTTP POST request. In another embodiment, for commands requiring high reliability, a protocol with an acknowledgment mechanism can be used, retrying if no acknowledgment is received within a certain time to ensure reliable delivery of the command. Delivery can be asynchronous; the scheduler continues subsequent scheduling immediately after sending the message to improve system throughput.

[0088] Furthermore, the entire scheduling and delivery process can possess a certain degree of fault tolerance and adaptability. In one embodiment, when sending messages to a certain device node fails consecutively, the device can be temporarily marked as unavailable, messages sent to that device can be skipped, and logs or alarms can be issued simultaneously. The scheduler can also monitor the length of each queue, and when a queue is found to be severely backlogged, the polling weight can be dynamically adjusted to temporarily increase the processing frequency of that queue, thereby preventing queue overflow and achieving simple load awareness.

[0089] The embodiments described above construct an efficient and fair message scheduling and execution mechanism. This mechanism first intelligently classifies messages from device nodes into processing queues of different priorities based on their dynamic priority scores. Then, through a priority-weighted round-robin scheduling strategy, it ensures that messages in high-priority queues always receive more frequent processing opportunities, thus enjoying extremely low response latency, while also taking into account the basic service fairness of low-priority queues. Finally, after a message is dequeued, it is sent to the target device for execution through a reliable network protocol, supplemented by fault-tolerant retry and load-aware adaptive capabilities. This enables highly urgent control commands to be executed quickly and reliably, while ensuring the robustness of the system in handling sudden traffic surges and device anomalies. It achieves an efficient balance between timeliness, reliability, and system stability in control message transmission in smart home scenarios.

[0090] Based on any embodiment of the method in this application, before obtaining the service control messages generated in the smart home network, the method includes: Step S2100: In response to the user's trigger operation on the preset scene control on the smart home control terminal, a corresponding scene control instruction is generated, wherein the scene control instruction includes a scene identifier and a scene action; The starting point for the business control message transmission process can be responding to user interactions on the smart home control terminal. When a user needs to control a smart home scenario, they will trigger the corresponding operation through the control terminal interface they are using.

[0091] A smart home control terminal serves as the interface between the user and the smart home system, and it takes various forms. In one embodiment, the control terminal can be a mobile device carried by the user, such as a smartphone or tablet, with a dedicated smart home control application installed. The user triggers operations by clicking, swiping on the application's graphical interface, or issuing commands via a voice assistant. In another embodiment, the control terminal can be a device permanently installed in the home environment, such as a wall-mounted smart central control screen, a smart speaker with a screen, or a smart TV. The user operates it via a touchscreen or remote control. Furthermore, the control terminal can also be a purely voice-interactive device, where the user triggers scenarios by uttering specific voice commands.

[0092] Preset scene controls are interactive elements on the control terminal's user interface that represent a complete intelligent scene. Each preset scene control corresponds to a user-defined or system-preset scene configuration, such as Home Mode, Away Mode, Cinema Mode, Sleep Mode, etc. Controls can be represented as buttons, icons, list items, or short phrases of voice commands on a graphical interface. A user's triggering operation on a preset scene control is the initial event that initiates the entire control chain. In one embodiment, the triggering operation can be a tap on a touchscreen. In another embodiment, for a voice terminal, the triggering operation can be the user speaking a preset wake-up word and scene name, such as saying "So-and-so, turn on Cinema Mode."

[0093] When a user's trigger action on a preset scene control is detected, the control terminal generates a corresponding scene control instruction, which accurately expresses the user's intent. A scene control instruction contains at least two key data fields: a scene identifier and a scene action. The scene identifier is a string or code used to uniquely identify the specific scene the user wants to trigger. For example, when a user clicks the cinema mode button, the scene identifier in the generated scene control instruction might be `scene_cinema_mode`. The scene action describes the operation the user wishes to perform on the scene; the most common actions are activation or enabling, with corresponding actions like disabling or deactivating. For example, for cinema mode, the scene action is usually activation. Therefore, a complete scene control instruction can be represented at the data level as `{scene_id: "scene_cinema_mode", action:"activate"}`.

[0094] Step S2200: Based on the scene identifier, query the preset scene service mapping rules to determine the target service entity corresponding to the scene control instruction and the message template of the service control message to be generated; After generating scene control instructions, they need to be converted into business control messages according to preset scene business mapping rules. Specifically, the corresponding mapping rules can be determined by querying the scene identifier in the scene control instructions, thereby determining the corresponding target business entity and the template structure of the business control message to be generated.

[0095] Pre-defined scene business mapping rules define the correspondence between scene concepts at the user interaction level and internal system business logic entities, i.e., logical nodes. These rules can be stored in configuration files, embedded databases, or configuration services. In one embodiment, the scene business mapping rule can be a lookup table or a mapping table. This table uses the scene identifier as the key, and its corresponding value contains two key pieces of information: the target business entity and the message template for the business control message. The target business entity specifies the logical node or other type of node corresponding to this scene in the device state tree. For example, for a scene with the scene identifier "scene_cinema_mode", its mapping rule might specify that its target business entity is a logical node in the device state tree, with the identifier "logic_node_cinema". The message template defines the basic structure and default fields that the business control message generated for this scene should possess.

[0096] Identifying the target business entity is one of the key outputs of this step. The target business entity is a node identifier for a specific node in the device state tree, which can be mapped to a specific logical node within the device state tree. By using mapping rules to resolve scenario identifiers into target business entities, a bridge is established between user-friendly scenario names and precise business objects within the system.

[0097] Meanwhile, message templates also provide a blueprint for generating well-structured business control messages. Message templates define the required fields and optional default values ​​for business control messages. In one embodiment, the message template may specify that the business control message must include an entity identifier field for the target business entity, a business action field, and a preset scenario level field. The template can also provide default values ​​for certain fields; for example, it may provide a default level for the preset scenario level field based on the scenario type.

[0098] Step S2300: Based on the scenario action and the message template, generate a business control message containing the entity identifier, business action, and preset scenario level of the target business entity; After successfully acquiring scene control instructions and identifying the target business entity and message template, the user's operational intent can be encapsulated into a standardized business control message. Using the defined message template as a blueprint, dynamic information such as scene actions is populated into the corresponding fields of the template to generate a complete business control message. The message template defines the essential structure and fields of the message. For example, the template may stipulate that the message must include core fields such as the entity identifier of the target business entity, the business action, and the preset scene level. The generation process involves assigning specific values ​​to these fields. Scene actions directly originate from the scene control instructions triggered by the user, such as activation or deactivation. The entity identifier of the target business entity is obtained from the scene business mapping rules. The preset scene level can be predefined in the template according to the type or importance of the scene. For example, the preset scene level for security scenes can default to high, while the preset scene level for atmosphere adjustment scenes can default to low. By replacing the placeholders in the template with specific values, a complete and semantically clear business control message data object is finally generated.

[0099] In one embodiment, business control messages can be encapsulated using a lightweight data exchange format, such as JSON or XML, to ensure good readability and cross-platform compatibility. In another embodiment, the generation of business control messages can support parameterization. In addition to fixed fields, the message template can also include parameter placeholders. Scene control instructions themselves may carry specific parameters; for example, a user might want to set the light brightness in cinema mode to a specific value. When generating business control messages, these parameter values ​​can be extracted and filled into the corresponding placeholders in the message template, making the generated control instructions more precise and personalized.

[0100] Step S2400: Submit the generated business control message to the message bus or task queue for subsequent retrieval.

[0101] After generating business control messages, they need to be submitted to subsequent processing stages. To do this, the generated business control messages are submitted to an intermediate delivery mechanism, typically a message bus or a task queue. A message bus is an infrastructure component that supports a publish / subscribe pattern, allowing multiple producers to publish messages and multiple consumers to subscribe to and consume them. Publishing business control messages to specific topics on the message bus decouples message producers from subsequent processing services. A task queue is a buffering mechanism where task producers place pending tasks into the queue as messages, and one or more worker processes retrieve tasks from the queue for processing. Submitting business control messages as tasks to the task queue enables asynchronous task processing and load balancing.

[0102] The submission process can be synchronous, i.e., waiting for confirmation of successful submission before returning; or it can be asynchronous, returning immediately after submission without waiting for confirmation, to improve the initiator's response speed. After submitting the message to the bus or queue, the producer has completed its responsibility, and the subsequent message processing service, such as the service implemented according to the method of this application, retrieves the message from the bus or queue and performs a series of subsequent processing.

[0103] The embodiments described above first convert user-triggered scene operations on the control terminal into standardized scene control commands. Then, through preset mapping rules, user-friendly scene identifiers are accurately mapped to the corresponding target business entities in the device state tree, and message templates are determined. Subsequently, the commands are encapsulated into structured business control messages containing target entities, business actions, and preset scene levels according to the templates. Finally, they are submitted asynchronously through a message bus or task queue, thereby realizing the automatic, accurate, and efficient conversion of user intentions into internal system tasks. This greatly simplifies the development complexity of upper-layer applications, enabling users to drive complex distributed device collaborative control in the background through intuitive scene interaction. At the same time, it provides structurally standardized and semantically clear input for subsequent intelligent scheduling based on dynamic priorities, significantly improving the usability, scalability, and responsiveness of the entire smart home system.

[0104] Please see Figure 2 This application provides a service control message transmission device to meet one of its objectives. It is a functional embodiment of the service control message transmission method of this application. The device includes an entity determination module 3100, an information determination module 3200, a message generation module 3300, and a message scheduling module 3400. The entity determination module 3100 is configured to acquire service control messages generated in a smart home network and determine the target service entity specified in the service control message. The information determination module 3200 is configured to determine the association status information and relationship between the target node and the target service entity from the device status tree corresponding to the smart home network. The system includes associated control semantic information, wherein the device state tree contains device nodes representing physical devices, logical nodes representing logical functions, and spatial nodes representing physical locations, with nodes forming a hierarchical structure through reference relationships; the message generation module 3300 is configured to determine the controlled device nodes in the device state tree controlled by the target business entity based on the associated state information and associated control semantic information of the target node, and generate device node messages with dynamic priorities for each controlled device node; the message scheduling module 3400 is configured to schedule the device node messages to the corresponding message processing queues for distribution according to the dynamic priorities.

[0105] Based on any embodiment of the device in this application, the information determination module 3200 includes: a query determination module, configured to query a node in the device state tree that matches the entity identifier of the target business entity, and determine the node as the target node; a list acquisition module, configured to, when the target node is a logical node, acquire a reference list set in the device state tree to determine each device node referenced by the target node; a status acquisition module, configured to acquire the self-status information recorded in the target node and the self-status information of each referenced device node to form associated status information, wherein the self-status information includes one or more of the current active status and health indicators of the corresponding node; and a semantic acquisition module, configured to acquire pre-configured associated control semantic information in the target node, wherein the associated control semantic information includes mapping rules that map business actions in business control messages for the target node to one or more device-level control actions.

[0106] Based on any embodiment of the device in this application, the message generation module 3300 includes: a rule conversion module, configured to parse the business actions contained in the received business control message into device-level control commands for each determined controlled device node according to the mapping rules between business actions and device control actions defined in the associated control semantic information of the target node; a message creation module, configured to create a corresponding device node message for each parsed device-level control command, the device node message including the identifier of the target controlled device node, the device-level control command, and a priority field; a score determination module, configured to determine the dynamic priority score of each device node message based on one or more of the data including the associated status information of the target node, the preset scenario level of the business control message, and the real-time load status of the controlled device node; and a score assignment module, configured to assign the dynamic priority score to the priority field of the corresponding device node message, thereby completing the generation of device node messages with dynamic priorities.

[0107] Based on any embodiment of the device in this application, the score determination module includes: a factor extraction module, configured to extract a scenario criticality factor from the associated status information of the target node, extract a message urgency factor from the preset scenario level of the business control message, and extract a device availability factor from the real-time load status of the controlled device node; a factor weighting module, configured to assign preset weight coefficients to the scenario criticality factor, message urgency factor, and device availability factor respectively, wherein the weight coefficient of the message urgency factor is configured to be higher than the weight coefficient of the device availability factor; and a score calculation module, configured to determine the dynamic priority score of the device node message corresponding to the corresponding controlled device node based on each factor and its corresponding weight coefficient.

[0108] Based on any embodiment of the device in this application, the score calculation module includes: a summation calculation module, configured to perform weighted summation based on each factor and its corresponding weight coefficient, and use the summation result as an initial priority score; an overhead calculation module, configured to determine a communication overhead adjustment value based on the hop distance between the position of the controlled device node in the network topology of the smart home network and the control device that submitted the service control message, wherein the communication overhead adjustment value is positively correlated with the hop distance; and a score aggregation module, configured to subtract the communication overhead adjustment value from the initial priority score of the controlled device node to obtain the final dynamic priority score, wherein the communication overhead adjustment value is used as a negative adjustment item.

[0109] Based on any embodiment of the device in this application, the message scheduling module 3400 includes: a queue corresponding module, configured to determine the priority range to which the device node message belongs based on the dynamic priority score carried in the device node message, and allocate the device node message to the message processing queue corresponding to the corresponding priority range; a cyclic scheduling module, configured to cyclically check and dequeue the device node messages in each message processing queue in descending order of the priority range to which each message processing queue belongs; and a dequeue execution module, configured to respond to the dequeue event of the device node message, retrieve the device node message from the message processing queue, and send the device node message to the target controlled device node specified in the message for execution through the smart home network.

[0110] Based on any embodiment of the device in this application, prior to the entity determination module 3100, the device further includes: an operation response module, configured to generate a corresponding scene control instruction in response to a user's trigger operation on a preset scene control on a smart home control terminal, the scene control instruction including a scene identifier and a scene action; a rule mapping module, configured to query preset scene service mapping rules according to the scene identifier, and determine the target service entity corresponding to the scene control instruction and the message template of the service control message to be generated; a generation and construction module, configured to generate a service control message including the entity identifier of the target service entity, the service action, and the preset scene level according to the scene action and the message template; and a downlink transmission module, configured to submit the generated service control message to a message bus or task queue for subsequent retrieval.

[0111] To address the aforementioned technical problems, embodiments of this application also provide a computer device. For example... Figure 3The diagram shows the internal structure of a computer device. This 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 business control message transmission method. The processor of this computer device provides computing and control capabilities, supporting the operation of the entire computer device. The memory of this computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, they enable the processor to execute the business control message transmission method of this application. The network interface of this computer device is used for communication with a terminal. 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 contains 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 servers. In this embodiment, the memory stores the program code and data required to execute all modules / sub-modules in the service control message transmission 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 service control message transmission 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 transmitting service control messages, characterized in that, include: Obtain service control messages generated in the smart home network and identify the target service entity specified in the service control message; The associated status information and associated control semantic information of the target node corresponding to the target business entity are determined from the device status tree corresponding to the smart home network. The device status tree includes device nodes representing physical devices, logical nodes representing logical functions, and spatial nodes representing physical locations. The nodes form a hierarchical structure through reference relationships. Based on the associated status information and associated control semantic information of the target node, the controlled device nodes in the device status tree that are controlled by the target business entity are determined, and device node messages with dynamic priorities are generated for each controlled device node. Based on the dynamic priority, the device node messages are scheduled to the corresponding message processing queue for distribution.

2. The service control message transmission method according to claim 1, characterized in that, The status information and associated control semantic information of the target node corresponding to the target business entity are determined from the device status tree corresponding to the smart home network, including: In the device status tree, query the node that matches the entity identifier of the target business entity, and identify the node as the target node; When the target node is a logical node, the reference list set in the logical node is obtained from the device state tree to determine the various device nodes referenced by the target node; The target node obtains its own status information and the own status information of each referenced device node to form associated status information. The own status information includes one or more of the current active status and health indicators of the corresponding node. Obtain pre-configured associated control semantic information from the target node. The associated control semantic information includes mapping rules that map service actions in service control messages for the target node to one or more device-level control actions.

3. The service control message transmission method according to claim 1, characterized in that, Based on the associated state information and associated control semantic information of the target node, the controlled device nodes in the device state tree that are controlled by the target business entity are determined, and device node messages with dynamic priorities are generated for each controlled device node, including: Based on the mapping rules between business actions and device control actions defined in the associated control semantic information of the target node, the business actions contained in the received business control message are parsed into device-level control commands for each determined controlled device node. For each parsed device-level control command, a corresponding device node message is created, which includes the identifier of the target controlled device node, the device-level control command, and a priority field; Based on one or more of the following data: the associated status information of the target node, the preset scenario level of the service control message, and the real-time load status of the controlled device node, a dynamic priority score for each device node message is determined. The dynamic priority score is assigned to the priority field of the corresponding device node message to complete the generation of device node messages with dynamic priority.

4. The service control message transmission method according to claim 3, characterized in that, Based on one or more of the following data: the association status information of the target node, the preset scenario level of the service control message, and the real-time load status of the controlled device node, a dynamic priority score for each device node message is determined, including: Extract the scenario criticality factor from the associated status information of the target node, extract the message urgency factor from the preset scenario level of the business control message, and extract the device availability factor from the real-time load status of the controlled device node. Preset weight coefficients are assigned to the scenario criticality factor, message urgency factor, and device availability factor, respectively, wherein the weight coefficient of the message urgency factor is configured to be higher than the weight coefficient of the device availability factor. Based on each of the factors and its corresponding weight coefficient, the dynamic priority score of the device node message corresponding to the controlled device node is determined.

5. The service control message transmission method according to claim 4, characterized in that, Based on each of the aforementioned factors and their corresponding weight coefficients, the dynamic priority score of the device node message corresponding to the controlled device node is determined, including: The factors and their corresponding weight coefficients are weighted and summed, and the summation result is used as the initial priority score. Based on the hop count distance between the location of the controlled device node in the network topology of the smart home network and the controlling device that submitted the service control message, a communication overhead adjustment value is determined, and the communication overhead adjustment value is positively correlated with the hop count distance. The initial priority score of the controlled device node is subtracted from the communication overhead adjustment value to obtain the final dynamic priority score, wherein the communication overhead adjustment value is used as a negative adjustment term.

6. The service control message transmission method according to claim 1, characterized in that, Based on the dynamic priority, the device node messages are scheduled to the corresponding message processing queues for distribution, including: Based on the dynamic priority score carried in the device node message, determine the priority range to which it belongs, and allocate the device node message to the message processing queue corresponding to the corresponding priority range. The device node messages are checked and dequeued in a loop according to the priority range of each message processing queue from high to low. In response to the dequeue event of the device node message, the device node message is retrieved from the message processing queue and sent to the target controlled device node specified in the message for execution via the smart home network.

7. The service control message transmission method according to any one of claims 1 to 6, characterized in that, Before acquiring service control messages generated in the smart home network, the following steps are included: In response to the user's triggering operation on the preset scene control on the smart home control terminal, a corresponding scene control instruction is generated, which includes a scene identifier and a scene action; Based on the scene identifier, query the preset scene business mapping rules to determine the target business entity corresponding to the scene control instruction and the message template of the business control message to be generated; Based on the scenario action and the message template, generate a business control message containing the entity identifier, business action, and preset scenario level of the target business entity; The generated business control messages are submitted to the message bus or task queue for later retrieval.

8. A service control message transmission device, characterized in that, include: The entity determination module is configured to acquire service control messages generated in the smart home network and determine the target service entity specified in the service control message. The information determination module is configured to determine the associated status information and associated control semantic information of the target node corresponding to the target business entity from the device status tree corresponding to the smart home network. The device status tree includes device nodes representing physical devices, logical nodes representing logical functions, and spatial nodes representing physical locations. The nodes form a hierarchical structure through reference relationships. The message generation module is configured to determine the controlled device nodes in the device status tree controlled by the target business entity based on the associated status information and associated control semantic information of the target node, and generate device node messages with dynamic priorities for each controlled device node. The message scheduling module is configured to schedule the device node messages to the corresponding message processing queue for distribution based on the dynamic priority.

9. A computer device comprising a controller, the controller including a processor and a memory, characterized in that, The processor invokes and runs a computer program in the memory to perform the steps of the service control message transmission 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