Method, apparatus, storage medium and electronic device for controlling service function across devices

Abstract

This application discloses a method, apparatus, storage medium, and electronic device for controlling cross-device service functions, relating to the field of smart home technology. The method includes: when it is determined that a first device needs to call a service function of a second device, generating a service request message corresponding to the first device, wherein the service request message includes at least a first identifier bound to the first device; synchronizing the service request message to a service registration topic, and determining that the second device obtains acquisition data containing the first identifier from the service registration topic; and when a service response message is received, determining multiple service request messages carrying the same first identifier as the service response message, and determining the control result of the first device on different service functions on the second device based on the multiple service request messages, wherein the service response message is used to carry feedback information of the second device using the acquisition data, and the control result is used to indicate the operating status of the service function.

Description

Technical Field

[0001] This application relates to the field of smart home technology, and more specifically, to a method, apparatus, storage medium, and electronic device for controlling service functions across devices. Background Technology

[0002] With the rapid development of Internet of Things (IoT) technology, the construction of smart homes, industrial automation, and smart cities requires thousands of smart devices to achieve seamless interconnection and efficient interoperability. Traditional device communication and control methods are mostly based on centralized architectures. For example, smart home systems typically require a home gateway or cloud platform as an intermediary, but related technical solutions often rely on a centralized cloud platform or home gateway. All communication between devices must pass through a central node for routing and command forwarding. This not only increases the processing burden on the central node, becoming a system performance bottleneck, but also leads to the risk of single point of failure. Once the central node fails, the entire network will be paralyzed. Furthermore, in related solutions, the relationships between devices usually require manual, static configuration by the user (e.g., binding a switch to a light on a mobile app). When the number of devices is large or the network topology changes frequently, this configuration method is extremely cumbersome, inflexible, and difficult to manage. In addition, communication barriers often exist between devices of different brands and with different protocols, making it difficult to directly understand and execute each other's commands. While some standard protocols address connectivity at the communication layer, they do not solve the problems of "how devices understand what the other party is saying" and "how to securely authorize operations" at the application layer semantics.

[0003] Therefore, in related technologies, cross-device service function control between devices of different brands and with different protocols is complex and inefficient, and no effective solution has yet been proposed. Summary of the Invention

[0004] This application provides a method, apparatus, storage medium, and electronic device for controlling service functions across devices, in order to at least solve the problem in the related art that the process of controlling service functions across devices of different brands and with different protocols is complex and inefficient.

[0005] According to one embodiment of this application, a method for controlling service functions across devices is provided, comprising: when it is determined that a first device needs to call a service function of a second device, generating a service request message corresponding to the first device, wherein the service request message includes at least: a first identifier bound to the first device; synchronizing the service request message to a service registration topic, and determining that the second device obtains acquisition data containing the first identifier from the service registration topic; when a service response message is received, determining multiple service request messages carrying the same first identifier as the service response message, and determining a control result of the first device on different service functions on the second device based on the multiple service request messages, wherein the service response message is used to carry feedback information of the second device using the acquisition data, and the control result is used to indicate the operating status of the service function.

[0006] In an exemplary embodiment, determining the control result of the first device on different service functions on the second device based on the plurality of service request messages includes: parsing the plurality of service request messages and determining the target operating state carried by each service request message according to the parsing result; if the target operating state is normal operation, determining that the cross-device function call setting of the first device on the second device is successful; if the target operating state is any one of paused operation, stopped operation, or no operation information, determining that the cross-device function call setting of the first device on the second device fails, and generating a failure log.

[0007] In an exemplary embodiment, when the target operating state is normal operation, after determining that the cross-device function call setting of the first device to the second device is successful, the method includes: determining the call priority corresponding to the different service functions that have been successfully set, and sequentially completing the call according to the call priority and the waiting time corresponding to the different service functions; after completing the cross-device control of all different service functions, generating a prompt message indicating the end of the cross-device control of service functions between the first device and the second device, and adding a verification strategy for the cross-device control of service functions between the first device and the second device again.

[0008] In an exemplary embodiment, before generating a service request message corresponding to the first device when it is determined that the first device needs to invoke the service function of the second device, the method includes: configuring a first message queue telemetry transport protocol (MQTT) agent corresponding to the first device and a second message queue telemetry transport protocol agent corresponding to the second device; wherein the first message queue telemetry transport protocol agent and the second message queue telemetry transport protocol agent transmit messages through a preset message queue telemetry transport protocol, and both the first message queue telemetry transport protocol agent and the second message queue telemetry transport protocol agent communicate synchronously with the central server; generating a service registration result on the central server based on the first message queue telemetry transport protocol agent, the second message queue telemetry transport protocol agent, multiple first-type functions supported by the first device, and multiple second-type functions supported by the second device, wherein the service registration result is used to configure a first access permission for the first device to invoke functions on the second device, and a second access permission for the second device to invoke functions on the first device; generating synchronization tokens corresponding to different functions based on the service registration result, wherein the synchronization tokens are used to carry in the message to verify the validity of the current message.

[0009] In an exemplary embodiment, before determining that the first device needs to invoke the service function of the second device, the method includes: if the first device is connecting to the central server for the first time, sending a collection instruction to the first device, wherein the collection instruction is used to instruct the first device to send its device information and capability description to the central server, the device information including at least one of the following: a first identifier corresponding to the first device, a device model corresponding to the first device, and a security level corresponding to the first device; the capability description including at least one of the following: all target service functions that the first device can invoke, the cross-device control service interface for different service functions between the first device and the second device, and basic parameter information corresponding to the target service functions; receiving the first device information and the first capability description fed back by the first device based on the collection instruction, generating a device profile of the first device based on the first device information and the first capability description, and publishing the first capability description to the service registration topic.

[0010] In an exemplary embodiment, after generating a device profile for the first device based on the first device information and the first capability description, and publishing the first capability description to a service registration topic, the method further includes: if the first device needs to call a high-privilege service function on the second device, determining the current permissions of the first device and determining the target permission range that the second device allows the first device to call; if the high-privilege service function is not under the current permissions but exists within the target permission range, reconfiguring the permissions of the first device, and generating a target token based on the permission reconfiguration result, wherein the target token is used to be appended to the message sent by the first device to participate in permission verification.

[0011] In an exemplary embodiment, after monitoring the second device to obtain acquisition data containing a first identifier message from the service registration topic, the method further includes: when the acquisition data instructs the first device to simultaneously initiate calls to multiple service functions of the second device, determining the call time and target permissions corresponding to the multiple service functions; performing permission verification based on the target permissions and the configuration permissions in the device file corresponding to the first device; if the verification fails, sending a first prompt message indicating that the call cannot be made normally to the first device; and if the verification passes, sending a second prompt message indicating that the call can be made normally to the first device.

[0012] According to another aspect of the embodiments of this application, a control device for cross-device service functions is also provided, comprising: a generation module, configured to generate a service request message corresponding to the first device when it is determined that the first device needs to call the service function of the second device, wherein the service request message includes at least: a first identifier bound to the first device; a first determination module, configured to synchronize the service request message to a service registration topic and determine that the second device obtains acquisition data containing the first identifier from the service registration topic; and a second determination module, configured to determine, upon receiving a service response message, a plurality of service request messages carrying the same first identifier as the service response message, and determine the control result of the first device on different service functions on the second device based on the plurality of service request messages, wherein the service response message is used to carry feedback information of the second device using the acquisition data, and the control result is used to indicate the operating status of the service function.

[0013] According to yet another embodiment of this application, a computer-readable storage medium is also provided, in which a computer program is stored, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0014] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0015] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0016] In this embodiment, when the first device detects that it needs to invoke a service function of the second device, the control module of the first device constructs a service request message containing the unique identifier of the first device (first identifier), the unique identifier of the second device (second identifier), the service interface, the service function information to be invoked, and its parameters, based on the service request message template generated by its device capability modeling module. The service request message also carries a service request identifier bound to the first device to ensure correct matching of subsequent response messages. The first device publishes the service request message to a service registration topic, so that the second device or any other device can discover the first device's request by subscribing to this topic. The first device simultaneously monitors this topic to receive responses from other devices. After the second device obtains the first device's service request message from the service registration topic, the second device also publishes this service response message to the service registration topic. The first device monitors and receives the service response messages in the response topic, and confirms whether the expected service response has been received by comparing the service request identifier. Once a match is successful, the first device determines the cross-device control result based on the execution status and result information in the service response message. By adopting the above technical solution, devices publish their own capabilities and service interface information to service registration topics and receive service response messages by subscribing to response topics, thereby achieving direct communication and service invocation between devices and reducing dependence on a central server. This solves the problem of complex and inefficient cross-device service function control between devices of different brands and protocols, enabling automatic discovery and direct invocation between different devices without direct intervention from a central server. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the hardware environment for a cross-device control method of a service function according to an embodiment of this application;

[0020] Figure 2 This is a flowchart of a cross-device control method for service functions according to an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the structure of a multi-device dynamic networking and interoperability system according to an embodiment of this application;

[0022] Figure 4 This is a timing diagram of service registration and discovery, and inter-device service invocation according to embodiments of this application;

[0023] Figure 5 This is a structural block diagram of a cross-device control device for service functions according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, apparatus, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, apparatus, or devices.

[0026] According to one aspect of the embodiments of this application, a method for controlling service functions across devices is provided. This method is widely applicable to whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and intelligence house ecosystems. Optionally, in this embodiment, the above-mentioned method for controlling service functions across devices can be applied to, for example... Figure 1 The hardware environment shown consists of local terminal 102 and server 104. Figure 1 This is a schematic diagram of the hardware environment for a cross-device control method for service functions according to an embodiment of this application, such as... Figure 1As shown, server 104 is connected to local terminal 102 via a network and can be used to provide services (such as application services) to the terminal or clients installed on the terminal. A database can be set up on the server or independently to provide data storage services to server 104. Cloud computing and / or edge computing services can be configured on the server or independently to provide data processing services to server 104. Optionally, the aforementioned local terminal may include: a client device capable of initiating function calls, and a server device for providing service functions.

[0027] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless FiDelity), Bluetooth. Local terminal 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0028] This embodiment provides a method for controlling service functions across devices, applied to the aforementioned local terminal. Figure 2 This is a flowchart of a cross-device control method for service functions according to an embodiment of this application, the process including the following steps:

[0029] Step S202: If it is determined that the first device needs to call the service function of the second device, a service request message corresponding to the first device is generated, wherein the service request message contains at least: a first identifier bound to the first device;

[0030] Optionally, the above service request message may also include: a second identifier corresponding to the second device, a cross-device control service interface for different service functions between the first device and the second device, information on the service function to be called, and parameter information corresponding to the service function;

[0031] Understandably, when the first device (such as a smart air conditioner) detects that it needs to invoke a service function of the second device (such as a humidifier) ​​(e.g., read the current indoor humidity), it will generate a dedicated service request message. This message contains the following key elements: A first identifier bound to the first device: This is a unique identifier used to clearly identify the device issuing the request, ensuring that the response is accurately sent back to the correct requester. A second identifier corresponding to the second device: This specifies the target device for the service request, ensuring that the request is correctly routed to the intended receiving device. Service interface: This describes the specific way the first and second devices interact, including the method signature of the service call, parameter types, and expected return value format. Service function information to be invoked: This clearly indicates the target service function that the requester wishes to invoke, for example, obtaining the current temperature. Parameter information corresponding to the service function: This provides the specific parameters required when invoking the service function. For example, no additional parameters are needed when invoking the temperature retrieval service, but if it is invoking the air conditioner's temperature adjustment service, the target temperature parameter may need to be provided.

[0032] Step S204: Synchronize the service request message to the service registration topic, and determine that the second device obtains the acquisition data containing the first identifier message from the service registration topic;

[0033] Optionally, after the service request message is generated, the first device stores this message in a service registration topic in the MQTT protocol. MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe communication protocol suitable for resource-constrained devices and unstable network environments. The service registration topic acts like a bulletin board for device capabilities and services, allowing any device subscribed to the topic (not just the second device) to see the service request issued by the first device, thus enabling automatic discovery between devices. The first device will then monitor the behavior of the second device, waiting for its response to retrieve messages from the service registration topic.

[0034] Step S206: Upon receiving a service response message, determine multiple service request messages that carry the same first identifier as the service response message, and determine the control results of the first device on different service functions on the second device based on the multiple service request messages, wherein the service response message is used to carry feedback information of the second device using the acquired data, and the control results are used to indicate the operating status of the service function.

[0035] Optionally, when the first device receives a service response message with a specific first identifier, it immediately identifies and associates all service request messages with the same first identifier. This identifier is assigned at the initial stage of the service request to track and distinguish different service calls. By pairing service response messages with related service request messages, the first device can accurately understand the execution result of each service function, including but not limited to whether it was successfully executed, error codes or warning messages during execution, and updates to the running status after the function call. Based on this information, the first device can determine the control result, which comprehensively reflects the running status of all service functions. For example, if the service response message indicates that the temperature adjustment service of the smart air conditioner was successfully executed, but the air purification service failed due to a full filter, the first device will summarize this information to form a control result, which may be displayed as: "Temperature adjustment successful, air purifier status abnormal." This mechanism ensures that the first device can monitor the service function status on the second device in real time, take remedial measures in a timely manner, or adjust subsequent operation strategies, thereby improving the efficiency of the entire system and the user experience.

[0036] Through the above steps, when the first device detects that it needs to invoke a service function of the second device, the control module of the first device constructs a service request message containing the unique identifier of the first device (first identifier), the unique identifier of the second device (second identifier), the service interface, the information of the service function to be invoked, and its parameters, based on the service request message template generated by its device capability modeling module. The service request message also carries a service request identifier bound to the first device to ensure correct matching of subsequent response messages. The first device publishes the service request message to the service registration topic, so that the second device or any other device can discover the first device's request by subscribing to this topic. The first device also monitors this topic to receive responses from other devices. After the second device obtains the first device's service request message from the service registration topic, the second device also publishes this service response message to the service registration topic. The first device monitors and receives the service response message in the response topic, and confirms whether the expected service response has been received by comparing the service request identifier. Once a match is successful, the first device determines the cross-device control result based on the execution status and result information in the service response message. By adopting the above technical solution, devices publish their own capabilities and service interface information to service registration topics and receive service response messages by subscribing to response topics, thereby achieving direct communication and service invocation between devices and reducing dependence on a central server. This solves the problem of complex and inefficient cross-device service function control between devices of different brands and protocols, enabling automatic discovery and direct invocation between different devices without direct intervention from a central server.

[0037] In an exemplary embodiment, determining the control result of the first device on different service functions on the second device based on the plurality of service request messages includes: parsing the plurality of service request messages and determining the target operating state carried by each service request message according to the parsing result; if the target operating state is normal operation, determining that the cross-device function call setting of the first device on the second device is successful; if the target operating state is any one of paused operation, stopped operation, or no operation information, determining that the cross-device function call setting of the first device on the second device fails, and generating a failure log.

[0038] Optionally, the first device parses multiple service request messages, which is accomplished through a service proxy and communication module. These messages contain details of the service function requests to the second device, such as the request ID, service name, method name, and expected target running state. The target running state is the expected running condition when the first device makes a call to the second device, such as "running normally," "paused," or "stopped." This information is crucial for the first device to determine the success of the call. Subsequently, the first device checks the service response message corresponding to each service request message. If the service response message indicates that the second device has achieved the target running state of "running normally," the first device confirms that the cross-device function call to the second device was successfully set up. This indicates that the second device has accurately executed the service function according to the instructions of the first device, achieving the expected running effect, and can be considered a successful call. However, if the target running state reported by the service response message is any of "paused," "stopped," or "no running information," this usually means that a problem occurred during the call, and the second device failed to achieve or report the normal running state. In this case, the first device determines that the cross-device function call setup failed and records the failure log. The failure log will record the failed call ID, service function, secondary device ID, specific exception status, and timestamp in detail. This log is not only used for internal system troubleshooting and maintenance, but also serves as an important reference for operations and maintenance personnel or users to understand the device status, facilitating subsequent repairs or adjustments.

[0039] In summary, the above response parsing and status determination process not only ensures precise control and result feedback of service calls between devices, but also establishes an effective anomaly handling and logging mechanism, providing strong support for device management and fault diagnosis in the IoT environment. This enables system administrators or users in large-scale and complex IoT systems to quickly locate problems and take timely measures.

[0040] In an exemplary embodiment, when the target operating state is normal operation, after determining that the cross-device function call setting of the first device to the second device is successful, the method includes: determining the call priority corresponding to the different service functions that have been successfully set, and sequentially completing the call according to the call priority and the waiting time corresponding to the different service functions; after completing the cross-device control of all different service functions, generating a prompt message indicating the end of the cross-device control of service functions between the first device and the second device, and adding a verification strategy for the cross-device control of service functions between the first device and the second device again.

[0041] In other words, once a service function call is successfully confirmed, the first device will enter the management phase of call priority and time scheduling. The core of this phase is determining the call priorities of the different service functions that have been successfully configured, as well as their respective pending call times. Call priorities reflect which service functions need to be executed first in emergency or resource-constrained situations; this is typically based on the function's real-time requirements, security level, or user-defined settings. The pending call time is the predetermined moment or condition at which one or more service functions should be executed, which helps achieve time synchronization between devices or process automation. Based on these two key pieces of information, the first device will develop an optimized call schedule to ensure that service functions are called according to the predetermined priorities and times, meeting both emergency service needs and ensuring the orderly execution of routine services. For example, the security alarm service might be set to the highest priority, while the energy-saving dimming service is scheduled to execute automatically at night.

[0042] Optionally, once the first device has completed cross-device control of all different service functions—that is, all service functions have been successfully invoked and executed according to priority and scheduled execution time—it will generate a control completion message. This message serves as confirmation for both users and system administrators that inter-device collaboration has been completed, indicating that the current control cycle has safely ended. Simultaneously, the first device will add verification policies for subsequent cross-device control of service functions with the second device. This typically includes updating the trust level between devices, reconfirming authorization status, or enabling the latest version of the security protocol to ensure that subsequent inter-device communication and control activities can be conducted within the latest security framework, avoiding potential security risks or operational conflicts.

[0043] In an exemplary embodiment, before generating a service request message corresponding to the first device when it is determined that the first device needs to invoke the service function of the second device, the above method includes: configuring a first message queue telemetry transport protocol proxy (MQTT) corresponding to the first device and a second message queue telemetry transport protocol proxy corresponding to the second device; wherein the first message queue telemetry transport protocol proxy and the second message queue telemetry transport protocol proxy transmit messages through a preset message queue telemetry transport protocol, and both the first message queue telemetry transport protocol proxy and the second message queue telemetry transport protocol proxy communicate synchronously with the central server; generating a service registration result on the central server based on the first message queue telemetry transport protocol proxy, the second message queue telemetry transport protocol proxy, multiple first-type functions supported by the first device, and multiple second-type functions supported by the second device, wherein the service registration result is used to configure a first access permission for the first device to invoke functions on the second device, and a second access permission for the second device to invoke functions on the first device; generating synchronization tokens corresponding to different functions based on the service registration result, wherein the synchronization tokens are used to carry in the message to verify the validity of the current message.

[0044] In simple terms, when the first device decides to invoke the service function of the second device, the invocation process does not immediately begin with the generation of a service request message. Instead, it first performs a series of preparatory steps to ensure smooth and secure communication. Specifically, the first step is to configure Message Queuing Telemetry Transport Protocol (MQTT) proxies for both the first and second devices, namely, a first MQTT proxy and a second MQTT proxy. The MQTT proxy acts as a bridge between the devices and the central server, responsible for transmitting the devices' service requests and responses to the central server via the MQTT protocol, and vice versa. This design ensures standardized and efficient device communication, especially in environments with unstable networks or limited resources.

[0045] Next, the first and second message queue telemetry transport protocol proxies need to maintain synchronous communication with the central server. This process includes periodic heartbeat mechanisms and status updates to ensure the central server has real-time knowledge of the device's location, status, and communication capabilities. Based on this information, the central server can generate a service registration result, a comprehensive database containing all functional and service access permissions for both devices. The service registration result not only determines the first device's first access permission to call the second device's services but also defines the second device's second access permission to call the first device's services, thus achieving bidirectional flexibility for interoperability between devices. Furthermore, to ensure the security of communication between devices and the reliability of message transmission, a synchronization token mechanism based on the service registration result is introduced. Each function and service call is assigned a unique synchronization token, which serves as a security credential in message transmission to verify the validity of the current message. When the first device generates a service request message, the synchronization token is embedded in the message to prove the legitimacy of the call; upon receiving the request, the second device verifies the synchronization token. Only requests that pass verification are further processed, effectively preventing unauthorized access and the execution of malicious commands.

[0046] In summary, this embodiment establishes a secure, efficient, and decentralized device service invocation framework by pre-configuring a message queue telemetry transport protocol proxy, synchronizing with a central server, generating service registration results and synchronization tokens. This framework not only simplifies direct communication between devices but also improves overall interoperability and security through dynamic permission management and encrypted tokens.

[0047] In one exemplary embodiment, the method includes: when the first device is connecting to the central server for the first time, sending a collection instruction to the first device, wherein the collection instruction is used to instruct the first device to send its device information and capability description to the central server, the device information including at least one of the following: a first identifier corresponding to the first device, a device model corresponding to the first device, and a security level corresponding to the first device; the capability description including at least one of the following: all callable target service functions of the first device, cross-device control service interfaces for different service functions between the first device and the second device, and basic parameter information corresponding to the target service functions; receiving the first device information and the first capability description fed back by the first device based on the collection instruction, generating a device profile of the first device based on the first device information and the first capability description, and publishing the first capability description to the service registration topic.

[0048] In other words, when the first device (such as a new smart light bulb) attempts to connect to the central server, the management core of the network, the central server proactively sends a collection command to the device. The purpose of this command is to trigger the first device to report its basic information and capability description, so that the central server can understand and register the details of the new device. The content of the collected device information is crucial, including at least the first device's primary identifier (usually a unique ID used to accurately identify the device within the network), the device model (helping to distinguish different types of devices, such as smart light bulbs, thermostats, cameras, etc.), and the security level (describing the device's encryption capabilities and security features, used to formulate subsequent communication strategies and security protocols). This information comprehensively reflects the basic attributes of the first device and is an important component in building the device profile. The capability description focuses on the actual functions and services of the first device, covering at least all the target service functions that the first device can invoke (such as turning the light on and off, adjusting brightness), its cross-device control service interface for service functions with second devices (another device in the network, such as a smart switch), and the basic parameter information corresponding to these service functions (such as brightness level, temperature setting, etc.). By collecting this information, the central server can clearly define the role and capabilities of the primary device in the network, laying a solid foundation for further inter-device interoperability and service registration.

[0049] Once the central server receives the information from the first device based on the collection instructions, it will immediately perform the following operations: (1) Generate a device profile: Based on the information and capability description of the first device, the central server creates a detailed device profile, including the device's basic attributes, security policies, and a list of functional services. This will serve as a reference for subsequent device management, permission allocation, and security auditing. (2) Service registration: The central server will extract the parts of the first capability description regarding service interfaces and target service functions, and publish them to the service registration topic via the MQTT protocol. This action is equivalent to publicly declaring the capabilities of the first device on the network, enabling other devices (such as the second device) to subscribe to the topic and thus discover the existence of the first device and the specific services it can provide.

[0050] In an exemplary embodiment, after generating a device profile for the first device based on the first device information and the first capability description, and publishing the first capability description to a service registration topic, the method further includes: if the first device needs to call a high-privilege service function on the second device, determining the current permissions of the first device and determining the target permission range that the second device allows the first device to call; if the high-privilege service function is not under the current permissions but exists within the target permission range, reconfiguring the permissions of the first device, and generating a target token based on the permission reconfiguration result, wherein the target token is used to be appended to the message sent by the first device to participate in permission verification.

[0051] In short, when a first device (such as a smart door lock) needs to access high-privilege services on a second device (such as a home security system) (e.g., viewing real-time monitoring video from the home security system), the central server checks the first device's current permissions. These current permissions are registered in the device profile when the device first connects and reflect its default permission level within the system. This level may be insufficient to cover all high-privilege service calls. Simultaneously, the central server determines the target permission range that the second device allows the first device to access. This target permission range is declared by the second device when registering its services, specifying which devices can access its high-privilege services under certain conditions. If the high-privilege service the first device attempts to access exceeds its current permissions but falls within the target permission range allowed by the second device, the central server reconfigures the first device's permissions. This process includes temporarily or permanently upgrading the first device's permissions to ensure it can legally access the required services. After permission reconfiguration, the central server generates a target token, which serves as recognition and proof of the first device's new permissions. This target token is appended to all messages sent by the first device for subsequent permission verification. The use of a target token ensures the legitimacy of each service call. When the first device initiates a service call request to the second device, it must include the target token in the message. Upon receiving the request, the second device verifies the target token in the message to confirm whether the call request is within the allowed permission scope. If the token is valid and the requested service function is within the target permission scope, the second device will execute the service function and return the result; otherwise, the service call will be rejected, protecting the second device from unauthorized access.

[0052] In an exemplary embodiment, after synchronizing the service request message to the service registration topic and determining that the second device has obtained acquisition data containing the first identifier message from the service registration topic, the method further includes: when the acquisition data instructs the first device to simultaneously initiate calls to multiple service functions of the second device, determining the call time and target permissions corresponding to the multiple service functions; performing permission verification based on the target permissions and the configuration permissions in the device file corresponding to the first device; if the verification fails, sending a first prompt message indicating that the call cannot be made normally to the first device; and if the verification passes, sending a second prompt message indicating that the call can be made normally to the first device.

[0053] For example, the first device might need to simultaneously open the curtains, start the coffee machine, and adjust the room temperature in a morning wake-up mode. When the second device obtains a message containing the first identifier from the service registration topic, it analyzes the data to determine if it indicates simultaneous invocation of multiple service functions. If there is indeed a cross-device control requirement for service functions, the second device further determines the invocation time (i.e., priority or execution order) and the required target permissions (the permission level required to invoke specific high-privilege functions). Subsequently, the second device performs detailed permission verification based on the target permissions and the configuration permissions recorded in the first device's device file, through interaction with the central server or device file. The device file contains all known information about the first device within the system, including but not limited to its security level, historical invocation records, and current permission configuration. This verification process ensures that the first device possesses the necessary permissions to invoke specific service functions on the second device, effectively preventing unauthorized operations. If the permission verification fails, it means that the first device does not have sufficient permissions to simultaneously invoke all requested service functions on the second device. In this case, the second device will send a first prompt message to the first device indicating that the invocation is not possible. The prompt message may include the specific service function name and the reason for the verification failure, to help the first device understand the permission restrictions and possibly guide it to request higher permissions from the central server. Conversely, if the permission verification passes successfully, the second device will send a second prompt message to the first device allowing normal access, indicating that all requested service functions can be invoked according to the predetermined time sequence and execution conditions. After receiving the second prompt message, the first device will be able to execute various operations as planned, ensuring the smooth operation of the smart home scenario.

[0054] Optionally, when a first device (such as a smart speaker) attempts to call a service function on a second device (such as a smart lighting system), if the service call is successful, the service agent of the first device will perform a series of subsequent operations based on the matching results in the received service response message. Specifically, determining the call priority is the primary task, because multiple service functions may have different execution priorities; for example, the priority of an emergency alarm service is usually higher than that of a daily dimming service. The first device will determine an optimized execution order based on the preset priorities of these service functions and their pending call times (i.e., the time or conditions at which the service function should be executed). Subsequently, the first device will complete the call of the service functions one by one according to this order, ensuring that the established service process can proceed as expected, while also handling urgent or time-sensitive service needs. In addition, if the control of a service function across devices fails, the first device will analyze the matching results to locate the problem. Abnormal service functions, i.e., service functions that cannot be called, may be due to problems with the function itself, network transmission failures, or insufficient permissions. To find the exact cause, the first device will query the device file of the second device on the central server to look for records or descriptions related to the current abnormal service function, which will help the first device understand the reason for the failure. The reason for the failure may be that the second device does not support the service temporarily, the function has been disabled, or there are unresolved issues.

[0055] Understandably, when cross-device control of a service function fails, and the first device determines the specific information of the abnormal service function through analysis and matching results, it queries the central server to check the device file of the second device to see if a record of the abnormal service function exists. This query is performed through a dedicated API interface or service query topic to verify whether the second device has ever declared this service capability. If the current abnormal service function is not found in the device file of the second device, it means that the second device may not have registered the function, or the registration information may have expired or been lost. In this case, the first device will send a third prompt message to the second device to update its device file, prompting the second device to recheck its function registration status and update the device file on the central server in a timely manner to reflect the latest service function list.

[0056] On the other hand, if the device file confirms the existence of a currently abnormal service function, the first device will further check whether the service request message carries a target token, used to verify the permission to call the currently abnormal service function. The target token is issued by the central server after the permission verification is successful; it serves as proof of the first device's permission to call the second device's high-privilege service function. If the target token is not present, it indicates that the first device may have omitted the permission verification step during the call process, or it has not yet been authorized to call the high-privilege service function. In response, the first device will receive a fourth prompt message indicating that the call permission needs to be corrected, guiding it to apply for permission or reconfigure it to ensure that future service calls comply with security and management regulations.

[0057] To better understand the process of the above-mentioned cross-device control method for service functions, the following description, in conjunction with optional embodiments, further illustrates the flow of the above-mentioned cross-device control method for service functions, but is not intended to limit the technical solutions of the embodiments of this application.

[0058] As an optional implementation, this application proposes a multi-device dynamic networking and interoperability system based on the MQTT protocol, deployed on each smart device participating in the network. Figure 3 This is a schematic diagram of the structure of a multi-device dynamic networking and interoperability system according to an embodiment of this application, including: a device capability modeling module 32, a service registration and discovery module 34, a service proxy and communication module 36, and a security and authorization module 38.

[0059] Optionally, the device capability modeling module 32 is used to define and describe the functions (i.e., services) provided by the device itself. Each device abstracts its current functionality into one or more standardized service interfaces. For example, a light can provide a SwitchService, which includes methods such as turnOn(), turnOff(), and toggle(); a temperature sensor can provide a TemperatureSensorService, which includes the getCurrentTemperature() method. This module generates a device description file, which at least includes: a unique device ID, the device type, and a list of all the service interfaces it provides (including service names, methods, parameters, and return value formats).

[0060] Optionally, the service registration and discovery module 34 includes a service registration function and a service discovery function. The service registration function, after a device powers on and connects to the Message Queuing Telemetry Transport Protocol (MQTP) agent, announces the device's online status and capabilities by publishing its device description file to a predefined, system-level service registration topic (e.g., / sys / service / register). The service discovery function supports subscribing to the service registration topic for any device seeking services to listen for new device online status; or, it publishes a query request (e.g., by device type or service interface name) to a service query topic (e.g., / sys / service / discover). Upon receiving the query, the target device replies with its device description file via a point-to-point topic.

[0061] Optionally, the service proxy and communication module 36 provides a service proxy for each participating smart device and supports direct interaction between different devices. For example, each device runs a local service proxy. When device A (client) needs to call a service method of device B (server), device A's service proxy generates a unique request ID and constructs a standard service request message. This message includes: target device ID, service interface name, method name, parameters, and request ID. Device A's service proxy publishes this request message to a dynamic topic dedicated to service calls, in the format: / rpc / {deviceB_ID} / request. Device B's service proxy subscribes to the request topic associated with its own ID (i.e., / rpc / its own device ID / request). Upon receiving the request, it parses the message and executes the corresponding service method locally. After execution, device B's service proxy constructs a service response message, including: request ID, execution status (success / failure), return value (or error message), and publishes it to the general response topic: / rpc / {deviceA_ID} / response. Device A's service agent subscribes to / rpc / its own device ID / response. After receiving the response, it matches the original request based on the request ID and completes the entire asynchronous call process.

[0062] Optionally, the security and authorization module 38 ensures interoperability security by introducing a capability-based authorization mechanism. This means that when a device registers for a service, it declares the access permissions required for that service. This ensures that any device must obtain a capability token from a central server or through distributed consensus before invoking the services of other devices. This token is sent along with the service request message and verified by the server device.

[0063] As an optional implementation method, taking the interoperability of lights and switches in a smart home scenario as an example, the specific steps include:

[0064] Step 1) Device Online and Service Registration: a) The smart light Light_001 is powered on and connected to the message queue telemetry transmission protocol proxy. Its device capability modeling module generates a description file:

[0065] json{"deviceId":"Light_001","type":"SmartLight","services":[{"name":"SwitchService","methods":[{"name":" turnOn","parameters":[],"returns":"boolean"},{"name":"turnOff","parameters":[],"returns":"boolean"}]}]}.

[0066] b) The light publishes this description file to the topic / sys / service / register.

[0067] Step 2) Service discovery includes: a) After the wireless switch Switch_002 comes online, it needs to find a light. It publishes a query message {"type":"SmartLight"} to / sys / service / discover. b) After receiving the query, Light_001 directly replies with its own description file to the switch through the topic / rpc / Switch_002 / response.

[0068] Step 3) Service Invocation: The user presses the switch Switch_002. Its service proxy and communication module perform the following operations: Generate a request ID: req_123, construct a request message: json{"to":"Light_001","service":"SwitchService","method":"toggle","params":[],"requestId":"req_123","timestamp":1627890123} A3) Publish the message to the topic / rpc / Light_001 / request. Light_001's service proxy then receives the request, executes the toggle() method, and changes the light's state. Upon successful execution, Light_001 constructs a response message: json{"requestId":"req_123","status":"success","data":true}, and publishes the response to the topic / rpc / Switch_002 / response. Switch_002 receives the response and confirms the operation was successful. The entire process requires no central server involvement in business logic routing.

[0069] Optional, Figure 4 This is a timing diagram of service registration and discovery, and inter-device service calls according to embodiments of this application. The diagram clearly illustrates the process of control interaction between the smart light Light_001 and the wireless switch Switch_002 via a message queue telemetry transport protocol proxy.

[0070] In summary, this application leverages direct communication between devices, eliminating reliance on real-time routing from a central server for most operations. This significantly reduces the central server load, avoids single points of failure, and enhances system robustness. Furthermore, through a service registration and discovery mechanism, new devices automatically announce their capabilities upon joining the network, allowing other devices to automatically detect and establish connections, achieving plug-and-play functionality and greatly improving user experience and system flexibility. Moreover, to improve efficiency, a standardized device capability model and service-oriented interface are established, elevating device interaction from the raw data transmission level to the semantic level. This ensures that devices can interact like software modules calling APIs, shielding them from differences in underlying hardware and protocols. Simultaneously, the interaction between different devices is based on the MQTT "request-response" model, providing a synchronous / asynchronous call experience similar to RPC for device interoperability, guaranteeing the reliability of command delivery and result return, superior to a simple publish-subscribe model. Furthermore, a built-in authorization mechanism based on current device capabilities ensures that only authorized devices can call specific services, preventing malicious operations and ensuring system security.

[0071] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software device. This computer software device is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0072] Figure 5 This is a structural block diagram of a cross-device control device for service functions according to an embodiment of this application; as shown below. Figure 5 As shown, it includes:

[0073] The generation module 52 is used to generate a service request message corresponding to the first device when it is determined that the first device needs to call the service function of the second device, wherein the service request message includes at least: a first identifier bound to the first device;

[0074] The first determining module 54 is used to synchronize the service request message to the service registration topic and determine that the second device obtains the acquisition data containing the first identifier message from the service registration topic;

[0075] The second determining module 56 is configured to, upon receiving a service response message, determine multiple service request messages carrying the same first identifier as the service response message, and determine the control results of the first device on different service functions on the second device based on the multiple service request messages, wherein the service response message is used to carry feedback information of the second device using the acquired data, and the control results are used to indicate the operating status of the service function.

[0076] Using the aforementioned device, when the first device detects a need to invoke a service function of the second device, the control module of the first device constructs a service request message containing the unique identifier of the first device (first identifier), the unique identifier of the second device (second identifier), the service interface, the information of the service function to be invoked, and its parameters, based on the service request message template generated by its device capability modeling module. The service request message also carries a service request identifier bound to the first device to ensure correct matching of subsequent response messages. The first device publishes the service request message to a service registration topic, allowing the second device or any other device to discover the first device's request by subscribing to this topic. The first device simultaneously monitors this topic to receive responses from other devices. When the second device obtains the first device's service request message from the service registration topic, it also publishes this service response message to the service registration topic. The first device monitors and receives the service response messages in the response topic, comparing the service request identifier to confirm whether the expected service response has been received. Once a match is successful, the first device determines the cross-device control result based on the execution status and result information in the service response message. By adopting the above technical solution, devices publish their own capabilities and service interface information to service registration topics and receive service response messages by subscribing to response topics, thereby achieving direct communication and service invocation between devices and reducing dependence on a central server. This solves the problem of complex and inefficient cross-device service function control between devices of different brands and protocols, enabling automatic discovery and direct invocation between different devices without direct intervention from a central server.

[0077] In an exemplary embodiment, the second determining module is configured to parse the plurality of service request messages, determine the target operating state carried by each service request message based on the parsing result; if the target operating state is normal operation, determine that the cross-device function call setting of the first device to the second device is successful; if the target operating state is any one of paused operation, stopped operation, or no operation information, determine that the cross-device function call setting of the first device to the second device fails, and generate a failure log.

[0078] In an exemplary embodiment, the second determining module is configured to, when the target operating state is normal operation, determine the call priority corresponding to the different service functions that have been successfully set up after the first device successfully sets up the cross-device function call to the second device, and complete the call sequentially according to the call priority and the waiting time corresponding to the different service functions; when all different service functions are controlled across devices, generate a prompt message indicating the end of cross-device control of service functions between the first device and the second device, and add a verification strategy for cross-device control of service functions between the first device and the second device.

[0079] In one exemplary embodiment, the apparatus further includes: a generation module, configured to, before generating a service request message corresponding to the first device when it is determined that the first device needs to call the service function of the second device, configure a first message queue telemetry transmission protocol proxy corresponding to the first device and a second message queue telemetry transmission protocol proxy corresponding to the second device; wherein the first message queue telemetry transmission protocol proxy and the second message queue telemetry transmission protocol proxy transmit messages through a preset MQTT protocol, and both the first message queue telemetry transmission protocol proxy and the second message queue telemetry transmission protocol proxy communicate synchronously with the central server; generate a service registration result on the central server based on the first message queue telemetry transmission protocol proxy, the second message queue telemetry transmission protocol proxy, multiple first-type functions supported by the first device, and multiple second-type functions supported by the second device, wherein the service registration result is used to configure a first access permission for the first device to call the function on the second device, and a second access permission for the second device to call the function on the first device; generate synchronization tokens corresponding to different functions based on the service registration result, wherein the synchronization tokens are used to carry in the message to verify the validity of the current message.

[0080] In one exemplary embodiment, the apparatus further includes: a publishing module, configured to send a collection instruction to the first device before determining that the first device needs to invoke the service function of the second device, in the case that the first device is connecting to the central server for the first time, wherein the collection instruction is used to instruct the first device to send its device information and capability description to the central server, the device information including at least one of the following: a first identifier corresponding to the first device, a device model corresponding to the first device, and a security level corresponding to the first device; the capability description including at least one of the following: all target service functions that the first device can invoke, the cross-device control service interface for different service functions between the first device and the second device, and basic parameter information corresponding to the target service function; receiving the first device information and the first capability description fed back by the first device based on the collection instruction, generating a device profile of the first device based on the first device information and the first capability description, and publishing the first capability description to the service registration topic.

[0081] In one exemplary embodiment, the apparatus further includes: a configuration module, configured to, after generating a device profile for the first device based on first device information and a first capability description, and publishing the first capability description to a service registration topic, determine the current permissions of the first device and determine the target permission range that the second device allows the first device to invoke when the first device needs to invoke a high-privilege service function on the second device; and if the high-privilege service function is not under the current permissions but exists within the target permission range, reconfigure the permissions of the first device and generate a target token based on the permission reconfiguration result, wherein the target token is used to be appended to a message sent by the first device to participate in permission verification.

[0082] In one exemplary embodiment, the apparatus further includes: a verification module, configured to synchronize the service request message to a service registration topic, and after determining that the second device has obtained acquisition data containing the first identifier message from the service registration topic, and when the acquisition data instructs the first device to simultaneously initiate calls to multiple service functions of the second device, determine the call time and target permissions corresponding to the multiple service functions; perform permission verification based on the target permissions and the configuration permissions in the device file corresponding to the first device; if the verification fails, send a first prompt message indicating that the call cannot be made normally to the first device; if the verification passes, send a second prompt message indicating that the call can be made normally to the first device.

[0083] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same target processor; or, the above modules are located in different target processors in any combination.

[0084] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0085] Embodiments of this application also provide an electronic device, including a target memory and a target processor, wherein the target memory stores a computer program and the target processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0086] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0087] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0088] Embodiments of this application also provide a computer program that includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in any of the above method embodiments.

[0089] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0090] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0091] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of N computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or N modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0092] The foregoing has provided a detailed description of a cross-device control method, apparatus, storage medium, and electronic device for a service function provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for controlling service functions across devices, characterized in that, include: If it is determined that the first device needs to call the service function of the second device, a service request message corresponding to the first device is generated, wherein the service request message contains at least: a first identifier bound to the first device; The service request message is synchronized to the service registration topic, and it is determined that the second device obtains the acquisition data containing the first identifier message from the service registration topic; Upon receiving a service response message, multiple service request messages carrying the same first identifier as the service response message are identified, and control results of the first device on different service functions on the second device are determined based on the multiple service request messages. The service response message is used to carry feedback information of the second device using the acquired data, and the control results are used to indicate the operating status of the service function.

2. The method for controlling service functions across devices according to claim 1, characterized in that, Determining the control results of the first device on different service functions on the second device based on the multiple service request messages includes: Parse the multiple service request messages and determine the target running state carried by each service request message based on the parsing results; If the target operating state is normal, it is determined that the cross-device function call setting of the first device to the second device is successful; If the target running state is any one of paused operation, stopped operation, or no running information, it is determined that the cross-device function call setting of the first device to the second device has failed, and a failure log is generated.

3. The method for controlling service functions across devices according to claim 2, characterized in that, When the target operating state is normal, after determining that the cross-device function call setting of the first device to the second device is successful, the method includes: Determine the calling priority of different service functions that have been successfully configured, and complete the calls sequentially according to the calling priority and the waiting time of different service functions; After completing the control of all different service functions across devices, a prompt message is generated indicating the end of the cross-device control of service functions between the first device and the second device, and a verification strategy is added for the first device and the second device to control service functions across devices again.

4. The method for controlling service functions across devices according to claim 1, characterized in that, Before generating a service request message corresponding to the first device, when it is determined that the first device needs to invoke the service function of the second device, the method includes: Configure a first message queue telemetry transport protocol (MQTT) agent corresponding to the first device and a second message queue telemetry transport protocol agent corresponding to the second device; wherein, the first message queue telemetry transport protocol agent and the second message queue telemetry transport protocol agent transmit messages through a preset message queue telemetry transport protocol, and both the first message queue telemetry transport protocol agent and the second message queue telemetry transport protocol agent communicate synchronously with the central server. Based on the first message queue telemetry transmission protocol proxy, the second message queue telemetry transmission protocol proxy, multiple first-type functions supported by the first device, and multiple second-type functions supported by the second device, a service registration result is generated on the central server. The service registration result is used to configure the first access permission of the first device to call the functions on the second device, and the second access permission of the second device to call the functions on the first device. Based on the service registration result, a synchronization token corresponding to different functions is generated, wherein the synchronization token is used to carry in the message to verify the validity of the current message.

5. The method for controlling service functions across devices according to claim 1, characterized in that, Before determining that the first device needs to invoke the service function of the second device, the method includes: When the first device is connecting to the central server for the first time, a collection instruction is sent to the first device. The collection instruction is used to instruct the first device to send its device information and capability description to the central server. The device information includes at least one of the following: a first identifier corresponding to the first device, a device model corresponding to the first device, and a security level corresponding to the first device. The capability description includes at least one of the following: all callable target service functions of the first device, cross-device control service interfaces for different service functions between the first device and the second device, and basic parameter information corresponding to the target service functions. The system receives first device information and first capability description fed back by the first device based on the collection instruction, generates a device profile for the first device based on the first device information and the first capability description, and publishes the first capability description to the service registration topic.

6. The method for controlling service functions across devices according to claim 5, characterized in that, After generating a device profile for the first device based on the first device information and the first capability description, and publishing the first capability description to a service registration topic, the method further includes: When the first device needs to call a high-privilege service function on the second device, determine the current permissions of the first device and determine the target permission range that the second device allows the first device to call. If the high-privilege service function is not within the current permission range but exists within the target permission range, the first device is reconfigured for permissions, and a target token is generated based on the permission reconfiguration result. The target token is used to be appended to the message sent by the first device to participate in permission verification.

7. The method for controlling service functions across devices according to claim 1, characterized in that, After synchronizing the service request message to the service registration topic and determining that the second device has obtained acquisition data containing the first identifier message from the service registration topic, the method further includes: When the acquired data instructs the first device to simultaneously initiate calls to multiple service functions of the second device, the call time and target permissions corresponding to the multiple service functions are determined. Permission verification is performed based on the target permissions and the configuration permissions in the device file corresponding to the first device. If the verification fails, a first prompt message indicating that the call cannot be made normally is sent to the first device; If the verification is successful, a second prompt message allowing normal access is sent to the first device.

8. A control device for cross-device service functions, characterized in that, include: The generation module is used to generate a service request message corresponding to the first device when it is determined that the first device needs to call the service function of the second device, wherein the service request message includes at least: a first identifier bound to the first device; The first determining module is used to synchronize the service request message to the service registration topic and determine that the second device obtains the acquisition data containing the first identifier message from the service registration topic; The second determining module is configured to, upon receiving a service response message, determine multiple service request messages carrying the same first identifier as the service response message, and determine the control result of the first device on different service functions on the second device based on the multiple service request messages, wherein the service response message is used to carry feedback information of the second device using the acquired data, and the control result is used to indicate the operating status of the service function.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method according to any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images