Scheduling method and device among multiple devices, electronic device and storage medium

Abstract

The embodiment of the invention provides a scheduling method and device among multiple devices, an electronic device and a storage medium, and relates to the technical field of the Internet of Things, and the method comprises the steps that in a multi-device cooperation scene, each Internet of Things device inputs own device data into a block chain network, the smart contract calculates the device priority of each slave Internet of Things device relative to the master Internet of Things device according to the device data, the master Internet of Things device is the Internet of Things device actively initiating connection, the slave Internet of Things devices are the Internet of Things devices passively responding to connection, and then the master Internet of Things device is connected with the slave Internet of Things devices according to the device priority. Therefore, interaction is carried out based on the block chain, the difference of communication protocols between the devices is bypassed, effective identification and queuing between the devices are ensured, meanwhile, a dynamic priority mechanism is used, investigation can be carried out based on real-time multi-dimensional data, the scheduling flexibility is improved, and the communication security between the devices is improved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a scheduling method for multiple devices, a scheduling device for multiple devices, an electronic device, and a computer-readable storage medium. Background Technology

[0002] With the rapid development of Internet of Things (IoT) technology, more and more smart devices (such as smart home terminals, industrial sensors, medical monitoring equipment, etc.) are accessing the network through wireless communication technologies (such as WiFi, Bluetooth, ZigBee, etc.) and working collaboratively.

[0003] However, in multi-device collaboration scenarios, corresponding problems still exist:

[0004] 1. Device heterogeneity and protocol compatibility issues: IoT devices typically use different communication protocols (such as WiFi, Bluetooth, LoRa, etc.), while existing solutions (such as blockchain or centralized server solutions) are mostly optimized for a single protocol and lack a unified scheduling mechanism across protocols; 2. Poor scheduling flexibility: The scheduling mechanism of IoT devices cannot adapt to the dynamically changing IoT environment, etc.

[0005] Therefore, there is a need for a way to implement device systems in specific scenarios and improve scheduling flexibility. Summary of the Invention

[0006] The present invention provides a scheduling method, apparatus, electronic device, and computer-readable storage medium for multiple devices, in order to solve or partially solve the problems of device heterogeneity, poor protocol compatibility, and poor scheduling flexibility in scenarios involving collaboration of multiple IoT devices.

[0007] This invention discloses a scheduling method among multiple devices, applied to a blockchain network, wherein several IoT devices and smart contracts are registered in the blockchain network, and the method includes:

[0008] Each of the aforementioned IoT devices inputs its own device data into the blockchain network;

[0009] The smart contract calculates the device priority of each slave IoT device relative to the master IoT device based on the device data. The master IoT device is the IoT device that actively initiates the connection, and the slave IoT devices are the IoT devices that passively respond to the connection.

[0010] The master IoT device connects to the slave IoT device according to the device priority.

[0011] In some feasible implementations, calculating the device priority of each slave IoT device relative to the master IoT device based on the device data includes:

[0012] Determine the scheduling scenario for the main IoT device;

[0013] Determine the slave IoT devices relative to the master IoT device from the IoT devices;

[0014] Extract target device data that matches the scheduling scenario from the device data corresponding to each of the IoT devices;

[0015] The device priority of each slave IoT device relative to the master IoT device is calculated based on the target device data.

[0016] In some feasible implementations, the device data includes at least one of user behavior data, environmental data, periodic plan information, and device alarm information. Determining the scheduling scenario for the main IoT device includes:

[0017] The scheduling scenario for the main IoT device is determined by using one of the user behavior data, environmental data, periodic plan information, and device alarm information for scenario matching.

[0018] In some feasible implementations, determining the slave IoT device relative to the master IoT device from the IoT devices includes:

[0019] Obtain the device attributes corresponding to the main IoT device and the scenario parameters of the scheduling scenario;

[0020] Query the temporary device list corresponding to the main IoT device from the blockchain network;

[0021] Select IoT devices that match the device attributes and scene parameters from the temporary device list and use them as slave IoT devices corresponding to the master IoT device.

[0022] In some feasible implementations, the device attributes include at least one of device type, scene support information, and geographical location; the scene parameters include at least one of scene type and scene requirement parameters; and the step of selecting IoT devices that match the device attributes and scene parameters from the temporary device list as the slave IoT devices corresponding to the master IoT device includes:

[0023] Select IoT devices from the temporary device list that correspond to the device type, have the scenario support information, and correspond to the scenario type and meet the scenario requirement parameters as candidate IoT devices;

[0024] Extract the dynamic capability parameters corresponding to the candidate IoT devices from the device data corresponding to the candidate IoT devices;

[0025] Candidate IoT devices whose dynamic capability parameters meet the selection criteria are designated as slave IoT devices corresponding to the master IoT device.

[0026] In some feasible implementations, the target device data includes at least one of device battery level, network latency, user manual priority, device load, and historical connection stability. The step of calculating the device priority of each slave IoT device relative to the master IoT device based on the target device data includes:

[0027] The device priority of each slave IoT device relative to the master IoT device is obtained by calculating one of the following: device power, network latency, user manual priority, device load, and historical connection stability.

[0028] Among some feasible implementation methods are:

[0029] The IoT device generates a key pair for identifying the user's identity;

[0030] The IoT device obtains the corresponding identity registration information and submits the key to the identity registration information to the smart contract;

[0031] The smart contract registers the IoT device to the blockchain network based on the key pair and the identity registration information.

[0032] This invention also discloses a scheduling device for multiple devices, applied to a blockchain network, wherein a plurality of IoT devices and smart contracts are registered in the blockchain network, and the device includes:

[0033] A data input module is used for each of the IoT devices to input its own device data into the blockchain network;

[0034] The priority calculation module is used by the smart contract to calculate the device priority of each slave IoT device relative to the master IoT device based on the device data. The master IoT device is an IoT device that actively initiates the connection, and the slave IoT devices are IoT devices that passively respond to the connection.

[0035] A connection module is used for the master IoT device to connect to the slave IoT device according to the device priority.

[0036] In some feasible implementations, the priority calculation module is specifically used for:

[0037] Determine the scheduling scenario for the main IoT device;

[0038] Determine the slave IoT devices relative to the master IoT device from the IoT devices;

[0039] Extract target device data that matches the scheduling scenario from the device data corresponding to each of the IoT devices;

[0040] The device priority of each slave IoT device relative to the master IoT device is calculated based on the target device data.

[0041] In some feasible implementations, the device data includes at least one of user behavior data, environmental data, periodic plan information, and device alarm information, and the priority calculation module is specifically used for:

[0042] The scheduling scenario for the main IoT device is determined by using one of the user behavior data, environmental data, periodic plan information, and device alarm information for scenario matching.

[0043] In some feasible implementations, the priority calculation module is specifically used for:

[0044] Obtain the device attributes corresponding to the main IoT device and the scenario parameters of the scheduling scenario;

[0045] Query the temporary device list corresponding to the main IoT device from the blockchain network;

[0046] Select IoT devices that match the device attributes and scene parameters from the temporary device list and use them as slave IoT devices corresponding to the master IoT device.

[0047] In some feasible implementations, the device attributes include at least one of device type, scene support information, and geographical location; the scene parameters include at least one of scene type and scene requirement parameters; and the priority calculation module is specifically used for:

[0048] Select IoT devices from the temporary device list that correspond to the device type, have the scenario support information, and correspond to the scenario type and meet the scenario requirement parameters as candidate IoT devices;

[0049] Extract the dynamic capability parameters corresponding to the candidate IoT devices from the device data corresponding to the candidate IoT devices;

[0050] Candidate IoT devices whose dynamic capability parameters meet the selection criteria are designated as slave IoT devices corresponding to the master IoT device.

[0051] In some feasible implementations, the target device data includes at least one of the following: device battery level, network latency, user-manual priority, device load, and historical connection stability. The priority calculation module is specifically used for:

[0052] The device priority of each slave IoT device relative to the master IoT device is obtained by calculating one of the following: device power, network latency, user manual priority, device load, and historical connection stability.

[0053] Among some feasible implementation methods are:

[0054] A key generation module is used by the IoT device to generate key pairs for identifying its identity.

[0055] The information submission module is used for the IoT device to obtain the corresponding identity registration information and submit the key to the identity registration information to the smart contract;

[0056] The registration module is used by the smart contract to register the IoT device to the blockchain network based on the key pair and the identity registration information.

[0057] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0058] The memory is used to store computer programs;

[0059] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0060] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0061] The embodiments of the present invention have the following advantages:

[0062] In this embodiment of the invention, the technology is applied to a blockchain network. Several IoT devices are registered in the blockchain network, and smart contracts are configured. In a multi-device collaboration scenario, each IoT device inputs its own device data into the blockchain network. The smart contract calculates the device priority of each slave IoT device relative to the master IoT device based on the device data. The master IoT device is the one that actively initiates the connection, while the slave IoT devices are those that passively respond to the connection. Then, the master IoT device connects to the slave IoT devices according to their device priorities. Thus, in a multi-device collaboration scenario, when different IoT devices need to communicate, they can interact based on the blockchain, bypassing differences in communication protocols between devices. This ensures effective identification and queuing between devices. Furthermore, the use of a dynamic priority mechanism allows for evaluation based on real-time, multi-dimensional data, improving both scheduling flexibility and the security of communication between devices. Attached Figure Description

[0063] Figure 1 This is a flowchart illustrating the steps of a scheduling method among multiple devices provided in an embodiment of the present invention;

[0064] Figure 2 This is a schematic diagram of the device scheduling process provided in an embodiment of the present invention;

[0065] Figure 3 This is a structural block diagram of a scheduling device among multiple devices provided in an embodiment of the present invention. Detailed Implementation

[0066] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0067] As an example, with the development of smart home technology, smart home devices have become widely available in users' home environments, effectively improving their quality of life and convenience. However, in smart home scenarios, multi-device collaboration is inevitable, including smart security systems, environmental control, energy-saving lighting, health management, automatic cleaning, and home entertainment centers. In these scenarios, differences in device capabilities lead to heterogeneity and compatibility issues. Furthermore, device communication requires prioritization, but a single, static prioritization method is insufficient to meet practical needs, thus impacting the user experience.

[0068] Reference Figure 1 This diagram illustrates a flowchart of a scheduling method among multiple devices provided in an embodiment of the present invention. The method is applied to a blockchain network, in which several IoT devices and smart contracts are registered. Specifically, it may include the following steps:

[0069] Step 101: Each of the IoT devices inputs its own device data into the blockchain network;

[0070] Optionally, this embodiment of the invention takes a smart home scenario as an example for illustrative purposes. In a smart home scenario, multiple IoT devices (i.e., smart home devices) can be registered to the corresponding blockchain network. While achieving decentralization, data sharing and multi-device collaboration can be realized based on the blockchain network.

[0071] In some feasible implementations, for each IoT device in a smart home environment, a key pair for identification can be generated first, then the corresponding identity registration information can be obtained, and the key pair and identity registration information can be submitted to a smart contract. The smart contract can then register the IoT device to the blockchain network based on the key pair and identity registration information. By registering the IoT device to the corresponding blockchain network, a trusted identity foundation is provided for subsequent device discovery, priority calculation, and collaborative control, enabling the IoT device to securely participate in collaborative tasks on the blockchain network.

[0072] In practice, the registration process of IoT devices to the blockchain network is a systematic identity authentication and data on-chain process. This ensures that each device has a verifiable and unique identity within the collaborative network. Specifically, each IoT device generates a corresponding asymmetric encryption key pair upon initial startup. The private key is securely stored in the device's hardware security module, while the public key serves as the device's identity credential for on-chain storage. Furthermore, during registration, IoT devices need to prepare complete identity registration information, including a unique device identifier, public key, device type, supported scenarios, communication protocols, and other core metadata. The device identifier typically uses a hashed MAC (Media Access Control Address) address or serial number to ensure uniqueness.

[0073] After completing the preparations, IoT devices can initiate an on-chain request by calling the registration method of the blockchain smart contract. The registration transaction requires a data packet containing device information and a digital signature generated using the device's private key. The smart contract can first verify the validity of the signature to ensure the authenticity of the registration request. The contract logic will check whether the IoT device has already been registered to avoid duplicate registration, and then write the device information into the immutable storage of the blockchain, triggering a registration success event.

[0074] Furthermore, registered IoT devices need to periodically send heartbeat transactions to the blockchain to maintain their online status. These heartbeat messages not only update the device's activity status but also synchronize dynamic data such as battery level and network latency. Thus, throughout the registration process, measures such as secure key storage, data transmission signature verification, and anti-duplicate registration effectively ensure the security and reliability of device registration, while maintaining the real-time status of devices through the heartbeat mechanism. In addition, the decentralized device registration scheme provides a trusted identity foundation for subsequent device discovery, priority calculation, and collaborative control, enabling IoT devices to securely participate in collaborative tasks on the blockchain network.

[0075] Once an IoT device successfully registers with the blockchain network, it can input its own device data into the blockchain network during operation to enable data sharing, data processing, and device communication. This device data can include all data involved in the operation of the IoT device, such as user behavior data, environmental data, periodic schedule information, device alarm information, device type, scene support information, and geographical location. It covers user-related data, environmental data of the device's environment, the device's own parameters, and data generated during operation. This invention does not limit the scope of this data.

[0076] Step 102: The smart contract calculates the device priority of each slave IoT device relative to the master IoT device based on the device data. The master IoT device is the IoT device that actively initiates the connection, and the slave IoT devices are the IoT devices that passively respond to the connection.

[0077] In multi-device collaboration scenarios, based on the device data input by each IoT device in the blockchain network, smart contracts can calculate the corresponding device priority according to the device data. This device priority can be used to characterize the communication priority between IoT devices and other IoT devices. In this context, IoT devices can be categorized into master IoT devices that actively initiate connections and slave IoT devices that passively respond to connections. For example, master IoT devices can include gateways, routers, smartphones, and other control devices, while slave IoT devices can include sensors, actuators, and wearable devices. Priority determines the order in which multiple slave IoT devices establish communication connections with the master IoT device. Assuming the master IoT device is a gateway and the slave IoT devices are smart locks, smart air conditioners, and smart refrigerators, and that the device priorities of smart locks, smart air conditioners, and smart refrigerators decrease sequentially, then when establishing a communication connection with the gateway, the connection between the smart lock and the gateway is established first, followed by the connection between the smart air conditioner and the gateway, and then the connection between the smart refrigerator and the gateway, and so on. Thus, smart contracts can calculate the device priority of each IoT device based on device data. Using a dynamic priority mechanism, it is possible to examine the data based on real-time multi-dimensional data, which not only improves scheduling flexibility but also enhances the security of communication between devices.

[0078] In some feasible implementations, smart contracts can first determine the scheduling scenario for the master IoT device, then identify the slave IoT devices relative to the master IoT device from among the IoT devices, then extract target device data matching the scheduling scenario from the device data corresponding to each slave IoT device, and finally calculate the device priority of each slave IoT device relative to the master IoT device based on the target device data. Thus, after determining the master IoT device, the corresponding slave IoT devices are accurately selected based on the dynamic scenario adaptation process, which improves the linkage of multi-device collaboration. At the same time, by dynamically calculating priorities, it not only fits the actual application scenario, but also improves the flexibility of scheduling between devices.

[0079] It should be noted that the process of determining the main IoT device can be based on the device type and function of the IoT device, since its role can be coordination and scheduling, decision control, and data aggregation. For example, home gateways, industrial control centers, and edge computing nodes.

[0080] Once the master IoT device is identified, the corresponding scheduling scenario can be further determined based on its device data. Different master IoT devices, due to functional differences, can correspond to different scheduling scenarios, and the slave IoT devices requiring communication also differ across these scenarios. Optionally, the device data includes at least one of the following: user behavior data, environmental data, periodic plan information, and device alarm information. The smart contract can then use one of these three data sources for scenario matching to determine the scheduling scenario for the master IoT device. By determining the scheduling scenario, the targeting of slave IoT devices can be effectively improved, the scope and volume of data processing can be reduced, and data processing efficiency can be increased.

[0081] User behavior data can represent control commands input by users on the control terminal, such as manual scene switching and voice command history. This data can be collected through mobile application logs or voice assistant API (Application Programming Interface) callbacks. Environmental data can include ambient temperature, humidity, light intensity, and the presence of personnel, which can be obtained through reports from relevant sensors. Scheduled task information can be corresponding timed tasks, such as activating security mode at 9:00 AM on weekdays, which can be collected through timed tasks in smart contracts. Device alarm information can be prompts triggered under preset conditions, such as smoke alarms or camera motion detection, which can be collected through device emergency broadcast messages. Through different data collection channels, the data can be continuously updated to the blockchain network, enabling smart contracts to accurately analyze the scheduling scenarios corresponding to the main IoT devices based on the collected data.

[0082] Optionally, smart contracts can employ a hierarchical decision-making mechanism to ensure response priorities. For example, a smart contract can always prioritize processing device alarm information. When an emergency signal such as a smoke alarm or unauthorized intrusion is detected, a preset emergency scenario is immediately triggered. Secondly, user commands are processed with secondary priority. If the user has issued a scene-switching command within the last hour, the latest user intent is executed first. In the absence of emergency situations and user commands, the smart contract checks preset timed schedules. If the current time falls within a preset "night mode" period, the corresponding scene configuration is automatically executed. Finally, the hierarchical environmental adaptive decision-making within the smart contract can comprehensively analyze real-time environmental parameters. For example, when insufficient indoor lighting and human activity are detected, the system automatically switches to a warm lighting scene. This hierarchical decision-making mechanism ensures both the timeliness of emergency response and intelligent adaptation to regular scenarios.

[0083] Furthermore, to achieve efficient scenario-based decision-making, at the data acquisition layer, edge computing nodes preprocess and aggregate raw sensor data, only uploading key feature data to the blockchain, significantly reducing blockchain storage pressure. At the decision execution layer, an event-driven architecture is adopted, automatically triggering a scenario reassessment process when any decision element changes. For scenario predictions requiring complex calculations (such as recommendations based on user habits), smart contracts combine off-chain machine learning models with on-chain verification, ensuring data credibility while improving the intelligence level of decision-making. All scenario switching records and decision-making basis are fully stored on the blockchain, forming a traceable audit log, providing data support for smart contract optimization and anomaly analysis. This design fully leverages the trust-building advantages of blockchain in multi-party collaboration while ensuring the real-time performance and reliability of IoT smart contract responses through a layered processing mechanism.

[0084] In some examples, for the process of switching between home nighttime scenes, for the home gateway, it is assumed that the device data includes at least:

[0085] Time: 20:00 (Planned information defines night mode starting from 19:30); Environment: Light intensity = 20 Lux, Temperature = 25℃, Personnel presence = true; User behavior: No recent commands; Alarms: None.

[0086] Based on the above data, the smart contract can then execute the following decision-making process:

[0087] Check alarms → None;

[0088] Check user commands → None (last command was 6 hours ago);

[0089] Inspection plan → Current time is during night mode.

[0090] Output scenario: "night_mode" (Automatically turn off unnecessary lights and activate security cameras)

[0091] Once the scheduling scenario is determined, the smart contract needs to further filter out the corresponding slave IoT devices from the IoT devices to enable multi-device collaboration between the master and slave IoT devices. Optionally, the smart contract can first obtain the device attributes of the master IoT device and the scenario parameters of the scheduling scenario. Then, it can query the temporary device list corresponding to the master IoT device from the blockchain network, and then filter out the IoT devices that match the device attributes and scenario parameters from the temporary device list as the slave IoT devices corresponding to the master IoT device. Thus, based on the corresponding parameters, the smart contract can quickly filter out the relationship between devices, and at the same time, through mode conversion, achieve unified scheduling between multi-protocol devices. This allows the smart contract to focus only on the demand scenario in multi-device collaboration scenarios without having to deal with the differences in underlying protocols (such as communication protocols), realizing cross-protocol multi-device linkage.

[0092] In some feasible implementations, device attributes can describe the core metadata of the static characteristics and capabilities of IoT devices, while scenario parameters can be dynamic configurations describing the current scheduling task requirements. These parameters can be set by the master IoT device or the user to guide device selection. Device attributes include at least one of device type, scenario support information, and geographical location, while scenario parameters include at least one of scenario type and scenario requirement parameters. In the process of selecting slave IoT devices corresponding to the scheduling scenario, candidate IoT devices can be selected from a temporary device list that correspond to the device type, possess scenario support information, and meet the scenario requirement parameters. Then, the dynamic capability parameters corresponding to the candidate IoT devices are extracted from their device data. Finally, candidate IoT devices whose dynamic capability parameters meet the selection criteria are designated as slave IoT devices corresponding to the master IoT device. Thus, in the case of cross-protocol multi-device collaboration, based on device attributes and scenario parameters, associated slave IoT devices can be quickly and accurately selected. This allows for focus on the requirement scenario in multi-device collaboration scenarios without addressing differences in underlying protocols (such as communication protocols), achieving cross-protocol multi-device linkage.

[0093] Among them, device type refers to the functional classification of IoT devices, such as smart speakers, temperature and humidity sensors, security cameras, gateways, etc. Device type can avoid invalid device interactions (such as a speaker not connecting to another speaker), and support type-driven collaboration strategies (such as sensors prioritizing connection to gateway devices). Scene support information refers to the list of application scenarios supported by the device, such as audio streaming scenarios, security protection scenarios, etc. Scene support information can quickly filter IoT devices that do not match the scenario (such as temperature and humidity sensors not supporting audio streaming scenarios), and realize scenario-based device grouping management. Geographic location refers to the physical address of the main IoT device (such as coordinates or area code). Geographic location can limit the communication range of IoT devices (such as selecting only devices within 10 meters), and support location-aware scene triggering (such as automatically turning on lights when entering a room). Through relevant device attributes, slave IoT devices that can interact with the main IoT device, have the same or similar scenarios, and are located within a certain range can be filtered out, realizing precise positioning of IoT devices.

[0094] Furthermore, the scenario type can identify the collaborative scenario that needs to be executed, such as multi-room yinp or intrusion detection. Scenario types can be used to filter compatible IoT devices and trigger scenario-specific priority calculation rules (e.g., security scenarios prioritize low-latency devices). Scenario requirement information can be the specific technical indicators required for scenario execution, typically stored as key-value pairs. This information can further enhance the dynamic ability to filter IoT devices (e.g., codec support, minimum battery consumption) and support fine-grained resource allocation (e.g., 4K video streaming requires high-bandwidth devices). For example, scenario requirement parameters can be shown in Table 1 below:

[0095] Parameter name Example value use minBattery 30 Exclude devices with battery level below 30%. requiredCodec "AAC" Select only devices that support AAC audio encoding. maxLatency 100ms Filter devices with network latency exceeding 100ms allowedDistance 5m Choose equipment within a 5-meter range. hardwareLevel "high_performance" Match high-performance hardware (such as GPU-accelerated devices)

[0096] Table 1

[0097] Among them, minBattery can be the minimum power consumption; requiredCodec can be the encoding and decoding support; maxLatency can be the maximum network latency; allowedDistance can be the communication distance; hardwareLevel can be the hardware level, etc., which are not limited in this invention.

[0098] Through the above process, smart contracts can first significantly improve device discovery efficiency through rapid initial screening based on static metadata; second, the introduction of dynamic demand parameters ensures optimal resource allocation; and finally, all matching logic is verifiable on the blockchain, fundamentally eliminating the risk of counterfeit devices accessing the network and improving device security and efficient autonomy of collaboration among IoT devices.

[0099] In one example, assuming the scheduling scenario is a smart home security mode, the device attributes corresponding to the main IoT device include:

[0100] "Device Type": "Security Hub"

[0101] Supported Scenarios: ["Security Alerts"]

[0102] Geographic location: {Latitude: 47.6062, Longitude: -122.3321}

[0103] The scenario parameters for the scheduling scenario include:

[0104] Scene Type: Security Alert

[0105] "Requirement Parameters":

[0106] Minimum battery level: 50.

[0107] Maximum latency: 200 milliseconds

[0108] Permitted distance: 15 meters

[0109] Based on the above parameters, the smart contract's screening process for IoT devices may include:

[0110] Exclude non-security devices (such as smart bulbs).

[0111] Choose a camera / window sensor with a range of 15 meters, a battery level of ≥50%, and a latency of ≤200ms.

[0112] Ultimately, a highly reliable security equipment cluster is generated.

[0113] Furthermore, after filtering out the corresponding slave IoT devices, the smart contract can obtain the target device parameters corresponding to the slave IoT devices, and then calculate the device priority of each slave IoT device relative to the master IoT device based on the target device parameters, so that the master IoT device can determine the interaction priority between itself and each slave IoT device based on the device priority.

[0114] In some feasible implementations, the target device data includes at least one of the following: device power, network latency, user manual priority, device load, and historical connection stability. The smart contract can then use one of these factors to calculate the device priority of each slave IoT device relative to the master IoT device. This allows for the use of a dynamic priority mechanism, which can be examined based on real-time multi-dimensional data. This not only improves scheduling flexibility but also enhances the security of communication between devices.

[0115] It's important to note that device priorities differ across scheduling scenarios. The priority queuing order obtained by IoT devices through the blockchain network varies depending on the scenario. IoT devices can establish connections and communications based on this priority queuing order, and this order can be adjusted in real-time according to different scheduling scenarios. For example, when a smart contract focuses on power consumption and efficiency, higher power consumption and efficiency equate to higher priority. Different devices update their power consumption and efficiency information, which is then verified and consensus-building occurs on the blockchain network. Different devices request comparisons on the blockchain network, and the comparison results are published based on the smart contract's power consumption and efficiency. Devices then queue for connections and communications based on the comparison results. When a smart contract changes to prioritize younger contracts, different devices compare their results, which are published on the blockchain network. Devices then queue for connections and communications based on the updated comparison results.

[0116] In addition, users can manually set the device priority of IoT devices. Smart contracts can record the user-set priorities on the blockchain network, and IoT devices can connect and perform corresponding interactive operations based on the device priorities set by the user through the blockchain network.

[0117] In some examples, assuming the smart contract is currently configured with an energy efficiency-first strategy, it will prioritize the battery life of IoT devices, and the corresponding device prioritization process can be as follows:

[0118] Device A (80% battery, 20W power consumption) reports data to the blockchain;

[0119] Device B (60% battery, 15W power consumption) is updating its status synchronously.

[0120] The smart contract will then calculate automatically:

[0121] Score for Equipment A: 80 × 60 + (100 - 20) × 40 = 4800 + 3200 = 8000

[0122] Score for Device B: 60×60+(100-15)×40=3600+3400=7000

[0123] After the blockchain consensus verification, the priority queue is announced: Device A > Device B. It can be seen that the main IoT device can prioritize connecting to the high-energy-efficiency device A.

[0124] Assuming the smart contract is set to a real-time priority mode, when the business requirement changes to a low-latency priority mode, the smart contract can automatically switch the computational dimension, and the corresponding processing procedure can be as follows:

[0125] Device C (30ms latency, 95% connection success rate) updates network status;

[0126] Device D (50ms latency, 98% connection success rate) submits real-time data.

[0127] Smart contract recalculation:

[0128] Score for Equipment C: (100-30)×70+95×30=4900+2850=7750

[0129] Score for Device D: (100-50)×70+98×30=3500+2940=6440

[0130] After the new block is confirmed, the priority changes to: Device C > Device D. Therefore, the video conferencing system immediately switches to the low-latency device C.

[0131] Furthermore, in the manual intervention mode, assuming the user manually sets the medical device to the highest priority, the corresponding processing procedure can be as follows:

[0132] Medical monitors (marked as isMedicalDevice=true) automatically receive 10,000 base points;

[0133] Ordinary IoT devices are calculated according to standard rules.

[0134] During the process, even with 100% battery and 0ms latency, ordinary devices still scored lower than medical devices. This demonstrates that in emergency scenarios, vital sign monitoring devices should always be given priority access.

[0135] Through the above process, in multi-device collaboration scenarios, when different IoT devices need to communicate, they can interact based on blockchain, bypassing the differences in communication protocols between devices, ensuring effective identification and queuing between devices. At the same time, the use of a dynamic priority mechanism allows for evaluation based on real-time multi-dimensional data, which not only improves scheduling flexibility but also enhances the security of communication between devices.

[0136] Step 103: The master IoT device connects to the slave IoT device according to the device priority.

[0137] Once the smart contract calculates the device priority of each slave IoT device relative to the master IoT device, it can return the corresponding priority order to the master IoT device. This allows the master IoT device to connect to each slave IoT device sequentially according to its device priority. By using a dynamic priority mechanism, it can be examined based on real-time multi-dimensional data, which not only improves scheduling flexibility but also enhances the security of communication between devices.

[0138] For example, refer to Figure 2This diagram illustrates a device scheduling process provided in an embodiment of the present invention. Assuming there are devices A, B, and C, devices A, B, and C are first added to the blockchain network, registering their information. After registration, taking device A as an example, device A can report its current device data to the blockchain network so that the smart contract can dynamically calculate the priority scores corresponding to devices B and C and return the priority scores to device A. Device A then connects devices B and C according to the priority order returned by the blockchain network. Thus, in multi-device collaboration scenarios, when different IoT devices need to communicate, they can interact based on the blockchain, bypassing differences in communication protocols between devices, ensuring effective identification and queuing between devices. Simultaneously, the dynamic priority mechanism allows for real-time multi-dimensional data analysis, improving both scheduling flexibility and the security of communication between devices.

[0139] It should be noted that the embodiments of the present invention include, but are not limited to, the examples described above. It is understood that those skilled in the art can make further settings according to actual needs under the guidance of the ideas in the embodiments of the present invention, and the present invention does not limit such settings.

[0140] In this embodiment of the invention, the technology is applied to a blockchain network. Several IoT devices are registered in the blockchain network, and smart contracts are configured. In a multi-device collaboration scenario, each IoT device inputs its own device data into the blockchain network. The smart contract calculates the device priority of each slave IoT device relative to the master IoT device based on the device data. The master IoT device is the one that actively initiates the connection, while the slave IoT devices are those that passively respond to the connection. Then, the master IoT device connects to the slave IoT devices according to their device priorities. Thus, in a multi-device collaboration scenario, when different IoT devices need to communicate, they can interact based on the blockchain, bypassing differences in communication protocols between devices. This ensures effective identification and queuing between devices. Furthermore, the use of a dynamic priority mechanism allows for evaluation based on real-time, multi-dimensional data, improving both scheduling flexibility and the security of communication between devices.

[0141] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0142] Reference Figure 3This diagram illustrates a structural block diagram of a multi-device scheduling device provided in an embodiment of the present invention. The device is applied to a blockchain network, which registers several IoT devices and smart contracts. Specifically, it may include the following modules:

[0143] The data input module 301 is used for each of the IoT devices to input its own device data into the blockchain network;

[0144] The priority calculation module 302 is used by the smart contract to calculate the device priority of each slave IoT device relative to the master IoT device based on the device data, wherein the master IoT device is an IoT device that actively initiates the connection and the slave IoT devices are IoT devices that passively respond to the connection.

[0145] The connection module 303 is used for the master IoT device to connect to the slave IoT device according to the device priority.

[0146] In some feasible implementations, the priority calculation module 302 is specifically used for:

[0147] Determine the scheduling scenario for the main IoT device;

[0148] Determine the slave IoT devices relative to the master IoT device from the IoT devices;

[0149] Extract target device data that matches the scheduling scenario from the device data corresponding to each of the IoT devices;

[0150] The device priority of each slave IoT device relative to the master IoT device is calculated based on the target device data.

[0151] In some feasible implementations, the device data includes at least one of user behavior data, environmental data, periodic plan information, and device alarm information, and the priority calculation module 302 is specifically used for:

[0152] The scheduling scenario for the main IoT device is determined by using one of the user behavior data, environmental data, periodic plan information, and device alarm information for scenario matching.

[0153] In some feasible implementations, the priority calculation module 302 is specifically used for:

[0154] Obtain the device attributes corresponding to the main IoT device and the scenario parameters of the scheduling scenario;

[0155] Query the temporary device list corresponding to the main IoT device from the blockchain network;

[0156] Select IoT devices that match the device attributes and scene parameters from the temporary device list and use them as slave IoT devices corresponding to the master IoT device.

[0157] In some feasible implementations, the device attributes include at least one of device type, scene support information, and geographical location; the scene parameters include at least one of scene type and scene requirement parameters; and the priority calculation module 302 is specifically used for:

[0158] Select IoT devices from the temporary device list that correspond to the device type, have the scenario support information, and correspond to the scenario type and meet the scenario requirement parameters as candidate IoT devices;

[0159] Extract the dynamic capability parameters corresponding to the candidate IoT devices from the device data corresponding to the candidate IoT devices;

[0160] Candidate IoT devices whose dynamic capability parameters meet the selection criteria are designated as slave IoT devices corresponding to the master IoT device.

[0161] In some feasible implementations, the target device data includes at least one of the following: device battery level, network latency, user-manual priority, device load, and historical connection stability. The priority calculation module 302 is specifically used for:

[0162] The device priority of each slave IoT device relative to the master IoT device is obtained by calculating one of the following: device power, network latency, user manual priority, device load, and historical connection stability.

[0163] Among some feasible implementation methods are:

[0164] A key generation module is used by the IoT device to generate key pairs for identifying its identity.

[0165] The information submission module is used for the IoT device to obtain the corresponding identity registration information and submit the key to the identity registration information to the smart contract;

[0166] The registration module is used by the smart contract to register the IoT device to the blockchain network based on the key pair and the identity registration information.

[0167] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0168] In addition, this invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the above-described multi-device scheduling method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0169] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described multi-device scheduling method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0170] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0171] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, EEPROM, Flash, and eMMC, etc.) containing computer-usable program code.

[0172] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0173] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0174] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0175] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0176] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0177] The foregoing has provided a detailed description of a scheduling method and a scheduling device among multiple devices provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A scheduling method among multiple devices, characterized in that, Applied to a blockchain network in which several IoT devices and smart contracts are registered, the method includes: Each of the aforementioned IoT devices inputs its own device data into the blockchain network; The smart contract calculates the device priority of each slave IoT device relative to the master IoT device based on the device data. The master IoT device is the IoT device that actively initiates the connection, and the slave IoT devices are the IoT devices that passively respond to the connection. The master IoT device connects to the slave IoT device according to the device priority.

2. The method according to claim 1, characterized in that, The step of calculating the device priority of each slave IoT device relative to the master IoT device based on the device data includes: Determine the scheduling scenario for the main IoT device; Determine the slave IoT devices relative to the master IoT device from the IoT devices; Extract target device data that matches the scheduling scenario from the device data corresponding to each of the IoT devices; The device priority of each slave IoT device relative to the master IoT device is calculated based on the target device data.

3. The method according to claim 2, characterized in that, The device data includes at least one of the following: user behavior data, environmental data, periodic plan information, and device alarm information. Determining the scheduling scenario for the main IoT device includes: The scheduling scenario for the main IoT device is determined by using one of the user behavior data, environmental data, periodic plan information, and device alarm information for scenario matching.

4. The method according to claim 2 or 3, characterized in that, The step of determining the slave IoT device relative to the master IoT device from the IoT devices includes: Obtain the device attributes corresponding to the main IoT device and the scenario parameters of the scheduling scenario; Query the temporary device list corresponding to the main IoT device from the blockchain network; Select IoT devices that match the device attributes and scene parameters from the temporary device list and use them as slave IoT devices corresponding to the master IoT device.

5. The method according to claim 4, characterized in that, The device attributes include at least one of device type, scene support information, and geographical location; the scene parameters include at least one of scene type and scene requirement parameters; and the step of selecting IoT devices that match the device attributes and scene parameters from the temporary device list as the slave IoT devices corresponding to the master IoT device includes: Select IoT devices from the temporary device list that correspond to the device type, have the scenario support information, and correspond to the scenario type and meet the scenario requirement parameters as candidate IoT devices; Extract the dynamic capability parameters corresponding to the candidate IoT devices from the device data corresponding to the candidate IoT devices; Candidate IoT devices whose dynamic capability parameters meet the selection criteria are designated as slave IoT devices corresponding to the master IoT device.

6. The method according to claim 2, characterized in that, The target device data includes at least one of the following: device battery level, network latency, user manual priority, device load, and historical connection stability. The step of calculating the device priority of each slave IoT device relative to the master IoT device based on the target device data includes: The device priority of each slave IoT device relative to the master IoT device is obtained by calculating one of the following: device power, network latency, user manual priority, device load, and historical connection stability.

7. The method according to claim 1, characterized in that, Also includes: The IoT device generates a key pair for identifying the user's identity; The IoT device obtains the corresponding identity registration information and submits the key to the identity registration information to the smart contract; The smart contract registers the IoT device to the blockchain network based on the key pair and the identity registration information.

8. A scheduling device for multiple devices, characterized in that, Applied to a blockchain network, in which several IoT devices and smart contracts are registered, the device includes: A data input module is used for each of the IoT devices to input its own device data into the blockchain network; The priority calculation module is used by the smart contract to calculate the device priority of each slave IoT device relative to the master IoT device based on the device data. The master IoT device is an IoT device that actively initiates the connection, and the slave IoT devices are IoT devices that passively respond to the connection. A connection module is used for the master IoT device to connect to the slave IoT device according to the device priority.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-7.

10. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-7.

Images