A multi-protocol fusion-based internet of things core control method and system

Abstract

The application discloses a kind of based on multi-protocol fusion's internet of things core control method and system, it is related to internet of things and intelligent building control technical field.The method includes: by analyzing device configuration and constructing uniform device model library, multiple source control request is converted into uniform control task;Based on device identification, function identification and protocol type, task key is constructed to carry out deduplication scheduling, and is combined with task source priority, task effective time and manual protection time to complete conflict coordination;Based on protocol type, channel priority and current network state, target execution channel is screened and control is executed, and cloud edge state synchronization is realized by state version and offline operation log.Uniform device model, task deduplication conflict coordination and cloud edge state synchronization reduce the complexity of multi-protocol access, improve control stability and state consistency under network exception.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) and smart building control technology, specifically to a core IoT control method and system based on multi-protocol fusion. Background Technology

[0002] As the application of IoT technology continues to expand in smart buildings, smart parks, and whole-house smart home scenarios, devices such as lighting, HVAC, security, access control, audio-visual equipment, and environmental monitoring typically need to be connected to the same control system for unified management. Different types of devices often use different communication protocols, such as KNX, MQTT, TCP, UDP, SIP, and serial communication. These different protocols differ in terms of device addresses, functional descriptions, status feedback, and control channels. Therefore, the system needs to perform considerable adaptation processing during device access, control command conversion, and status maintenance.

[0003] Existing IoT control systems typically enable single-protocol device control, scene-linked control, or cloud-based remote control. However, in scenarios with mixed access of multiple protocol devices, the lack of a unified way to associate device data models, functional identifiers, and control channels can easily increase the complexity of device management and task scheduling. Especially when user manual control, scene triggering, automation rules, security alarms, cloud-based remote control, and edge local control coexist, the same device may receive multiple control tasks for the same function within a short period of time. Without an effective task deduplication and conflict coordination mechanism, issues such as duplicate task distribution, subsequent tasks overwriting previous tasks, and automation rules controlling user operations in reverse may occur, affecting device control stability and user experience.

[0004] Furthermore, some IoT control systems rely on cloud channels for remote control and status synchronization. When the network is unavailable or the cloud connection is abnormal, inconsistencies can easily arise between local control, edge control, and device status synchronization. After the network is restored, the lack of comparison processing of offline control records, device status versions, and cloud status versions may lead to inconsistencies between local and cloud device states. Therefore, in multi-protocol fusion control scenarios, how to uniformly model multi-protocol devices, deduplicate and coordinate conflicting control tasks from multiple sources, and maintain good control continuity and status consistency between cloud, edge, and local protocol channels are issues that core IoT control systems need to address. Summary of the Invention

[0005] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a core control method and system for the Internet of Things based on multi-protocol fusion, so as to solve the above-mentioned technical problems.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a core control method for the Internet of Things based on multi-protocol fusion, comprising: S1: Initialize core services and parse device configuration to generate basic data for service operation; S2: Collect information on multi-protocol devices, perform unified modeling of multi-protocol device information based on service operation basic data, and generate a unified device model library containing device identifier, function identifier, protocol type and channel priority; S3: Receive control requests from multiple sources, determine the target device and target function based on the unified device model library, and generate a unified control task that includes device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity period; S4: Construct task keys based on device identifier, function identifier and protocol type, perform deduplication scheduling on unified control tasks, and generate deduplication scheduling results; S5: Based on the priority of the task source, the effective time of the task, and the preset manual protection time, the deduplication scheduling results corresponding to the same function of the same device are reconciled to generate tasks to be executed. S6: Based on protocol type, channel priority and current network status, the target execution channel is determined from cloud channels, edge channels and local protocol channels by using channel availability filtering and priority matching methods. The task to be executed is then executed through the target execution channel, generating device status data and task execution results. S7: Generates a status version based on device status data, updates the device status cache, records offline operation logs containing the status version when the network is unavailable, and performs cloud-edge status synchronization based on the offline operation logs and status version when the network is restored.

[0007] The present invention is further configured such that S1 includes: Read service registration data and device configuration data, and determine the startup order and dependencies of core services based on the service registration data; Initialize core services according to startup order and dependencies, parse device configuration data, and obtain configuration parsing results; Generate basic data for service operation based on the initialization status and configuration parsing results of the core services.

[0008] The present invention is further configured such that S2 includes: Collect multi-protocol device information from device configuration, protocol discovery, and device registration records; Based on service operation data, determine the available protocol channels corresponding to multi-protocol device information; The multi-protocol device information is mapped according to the preset unified device fields. Based on the device identifier, the protocol address corresponding to the available protocol channel and the device function information configured by the device, the multi-protocol device information corresponding to the same physical device is merged to generate a unified device object. A unified device model library is generated based on the unified device object.

[0009] The present invention is further configured such that determining the target device and target function based on a unified device model library includes: Parse control requests from multiple sources to obtain request source type, target description information, and control target information. The request source type includes: user manual control, manual scenario, event-triggered scenario, automation rule, security alarm, cloud remote control, and edge local control. The target description information includes at least one of device identifier, spatial information, and device type. The control target information includes: function description and target parameters. The target device is matched in the unified device model library based on the target description information, and the target function is determined based on the function identifier and function parameter range corresponding to the target device.

[0010] The present invention is further configured such that generating a unified control task includes: Based on the target device and target function, extract the device identifier, function identifier, and protocol type from the unified device model library; The task source priority is determined based on the request source type and preset source priority rules. The preset source priority rules include: security alarms are higher than user manual control and manual scenarios; user manual control and manual scenarios are higher than event-triggered scenarios; event-triggered scenarios are higher than automation rules; and cloud remote control and edge local control are determined according to preset permission levels. Based on the request source type of the multi-source control request, the task validity time is matched from the preset task validity time configuration; Based on the target parameters in the control target information and the range of functional parameters corresponding to the target equipment, the parameter parsing and range verification method is used to determine the task target parameters. A unified control task is generated based on device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity period.

[0011] The present invention is further configured such that S4 includes: Construct a task key using the device identifier, function identifier, and protocol type in the unified control task, and query whether there is an existing task with the same task key in the queue of tasks to be executed; If no task already exists, the current unified control task is written into the task queue to be executed. When an existing task exists, the task processing type is determined based on the function identifier, task target parameters, and request source type. The task processing type includes target value update type, switch status update type, scene sequence type, and security alarm type. Based on the task processing type and the execution status of existing tasks, the system performs overwrite, sequential retention, priority retention, or correction processing on the current unified control task and existing tasks, updates the queue of tasks to be executed, and generates deduplication scheduling results.

[0012] The present invention is further configured such that S5 includes: Identify multiple deduplication scheduling results corresponding to the same device and the same function based on device identifier and function identifier; The execution order of multiple deduplication scheduling results is determined based on the priority of the task source, and the effective execution range of multiple deduplication scheduling results is determined based on the effective time of the task. When multiple deduplication scheduling results include deduplication scheduling results corresponding to user manual control, the deduplication scheduling results corresponding to the automation rules are restricted from performing reverse control on the same device and the same function within the preset manual protection time. Tasks to be executed are generated based on the execution order, effective execution scope, and reverse control constraints.

[0013] The present invention is further configured such that S6 includes: Obtain the current network status and the channel status of cloud channels, edge channels, and local protocol channels; Based on the protocol type in the task to be executed, candidate execution channels are selected from cloud channels, edge channels, and local protocol channels; Based on the channel status of candidate execution channels, channel availability is filtered to obtain available execution channels; Based on the channel priority in the unified device model library, the target execution channel is determined from the available execution channels; The task to be executed is executed through the target execution channel, and the device status data and task execution results are generated based on the execution feedback returned by the target execution channel.

[0014] The present invention is further configured such that S7 includes: A status version is generated based on the device status data, and the device status cache is updated by combining the device status data and the status version. When the current network status is unavailable, generate an offline operation log containing the status version based on the task to be executed, the task execution result, and the status version; When the current network status recovers from unavailable to available, read the offline operation log and obtain the status version corresponding to the cloud device status; Based on the status version in the offline operation log and the corresponding status version of the cloud device, status consistency processing is performed to generate cloud-edge status synchronization results. Update the device status cache and cloud device status based on the cloud-edge status synchronization results.

[0015] The present invention also provides a core control system for the Internet of Things based on multi-protocol fusion, the system comprising: Service initialization module: Initializes core services and parses device configuration to generate basic data for service operation; Unified Device Modeling Module: Collects information on devices with multiple protocols, performs unified modeling on the information on devices with multiple protocols based on service operation data, and generates a unified device model library that includes device identifier, function identifier, protocol type and channel priority; Control task generation module: Receives control requests from multiple sources, determines the target device and target function based on the unified device model library, and generates a unified control task that includes device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity period; Task deduplication and scheduling module: Constructs task keys based on device identifier, function identifier and protocol type, performs deduplication and scheduling of unified control tasks, and generates deduplication and scheduling results; Task conflict coordination module: Based on task source priority, task validity time, and preset manual protection time, it coordinates the conflict of deduplication scheduling results corresponding to the same function of the same device and generates tasks to be executed. Channel selection and execution module: Based on protocol type, channel priority and current network status, it uses channel availability filtering and priority matching methods to determine the target execution channel from cloud channels, edge channels and local protocol channels, and executes the task to be executed through the target execution channel, generating device status data and task execution results; State synchronization closed-loop module: Generates state version based on device state data, updates device state cache, records offline operation logs containing state version when the network is unavailable, and performs cloud-edge state synchronization based on offline operation logs and state version when the network is restored.

[0016] This invention provides a core control method and system for the Internet of Things (IoT) based on multi-protocol fusion. The method comprises: S1: Initializing core services and parsing device configurations to generate basic service operation data; S2: Collecting multi-protocol device information and performing unified modeling based on the basic service operation data to generate a unified device model library containing device identifiers, function identifiers, protocol types, and channel priorities; S3: Receiving control requests from multiple sources, determining the target device and target function based on the unified device model library, and generating a unified control task containing device identifiers, function identifiers, protocol types, request source types, task target parameters, task source priorities, and task validity periods; S4: Constructing task keys based on device identifiers, function identifiers, and protocol types, and performing deduplication scheduling on the unified control tasks. S5: Based on task source priority, task validity time, and preset manual protection time, conflict coordination is performed on the deduplication scheduling results corresponding to the same function of the same device to generate tasks to be executed; S6: Based on protocol type, channel priority, and current network status, channel availability filtering and priority matching methods are used to determine the target execution channel from cloud channels, edge channels, and local protocol channels, and the tasks to be executed are executed through the target execution channel, generating device status data and task execution results; S7: A status version is generated based on the device status data, the device status cache is updated, and offline operation logs containing the status version are recorded when the network is unavailable. When the network recovers, cloud-edge status synchronization is performed based on the offline operation logs and status version. The beneficial effects include: Unified access across multiple protocols: Available protocol channels are determined by service operation basic data, and multi-protocol device information is mapped and merged according to unified device fields. A unified device model library containing device identifier, function identifier, protocol type and channel priority is constructed, which helps to reduce the complexity of multi-protocol device access and control adaptation and improve the consistency of device management.

[0017] Stability of control task execution: Deduplication scheduling is performed by constructing task keys based on device identifier, function identifier, and protocol type. Then, based on task source priority, task validity time, and manual protection time, conflict coordination is performed on tasks corresponding to the same function on the same device. This helps to reduce duplicate distribution, reverse overwriting of manual control by automation rules, and conflicts between multiple source controls, thereby improving the stability of control task execution.

[0018] Cloud-edge collaborative reliability: By using channel availability filtering and priority matching methods to select cloud channels, edge channels, or local protocol channels, local control is maintained through available edge channels or local protocol channels when the cloud network is unavailable. After the network is restored, cloud-edge state synchronization is performed based on the state version and offline operation logs, which helps to improve control continuity and state recovery consistency in network anomaly scenarios.

[0019] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart illustrating an exemplary embodiment of the present invention is provided for a core control method for the Internet of Things based on multi-protocol fusion. Figure 2 This is a schematic diagram illustrating the structure of an IoT core control system based on multi-protocol fusion, as an exemplary embodiment of the present invention. Detailed Implementation

[0021] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0022] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0023] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0024] Example 1: A core control method for the Internet of Things based on multi-protocol fusion, such as Figure 1 As shown, it includes: S1: Initialize core services and parse device configurations to generate basic data for service operation.

[0025] Specifically, after the system starts, it reads service registration data and device configuration data. Service registration data includes service identifier, service type, dependent service identifier, startup order configuration value, activation status, initialization timeout time and exception handling strategy. Device configuration data includes device identifier, device type, spatial information, protocol connection information, device function information, device reporting cycle, channel priority, status readback capability, function mapping relationship, cloud connection parameters and edge connection parameters.

[0026] This invention uses JSON format to store service registration data and device configuration data by default. It checks the integrity and format of fields through JSON pattern validation rules. Among them, the service identifier cannot be empty, the dependent service identifier must exist in the service registration data, the startup order configuration value is a positive integer, and the activation status is an enabled identifier or a disabled identifier. The initialization timeout is 30 seconds by default, which can be configured within the range of 10 seconds to 120 seconds. When no external communication connection is required, 10 seconds to 30 seconds is preferred. When cloud connection, edge connection or protocol channel connection is required, 30 seconds to 120 seconds is preferred.

[0027] After the configuration verification is passed, core service nodes are established using service identifiers, and core service dependencies are established using dependent service identifiers. The startup order of core services is determined by topology sorting. Services with the same sorting level are arranged in ascending order according to the startup order configuration value. If topology sorting cannot be completed, a circular dependency is determined, a circular dependency exception record is generated, and the startup of core services involving circular dependencies is stopped.

[0028] The configuration service, device service, scenario service, automation service, security service, cloud service, edge service, and multi-protocol communication service are initialized sequentially according to the core service startup order. The initialization process includes loading service configurations, establishing communication connections, registering event listeners, and establishing runtime caches. If a core service fails to return an initialization success message within the initialization timeout period, it will retry, skip, degrade, or terminate the startup according to the exception handling strategy. This invention defaults to 3 retries, and the number of retries can be configured from 1 to 5. The default retry interval is 5 seconds, which can be configured from 3 to 30 seconds. The system startup will terminate if the configuration service, device service, or multi-protocol communication service fails to retry, while other core services are allowed to skip or degrade when they fail to retry.

[0029] The configuration service calls the JSON parser to extract device configuration data, checking the protocol address, device function parameter range, spatial information, cloud connection parameters, and edge connection parameters. The device reporting cycle must be a positive number, the channel priority must be between level 1 and 3, the status readback capability must use a supported or unsupported identifier, and the function mapping relationship must include the function identifier and function parameter range. After the configuration verification passes, the configuration parsing result is generated. The configuration parsing result is sent to each core service through the event bus. After each core service loads the corresponding configuration, it returns the core service initialization status: initialization successful, initialization failed, degraded operation, or unavailable.

[0030] The system aggregates the initialization status of core services, core service dependencies, core service startup order, and configuration resolution results to generate basic service operation data. This basic service operation data includes service identifier, service type, core service initialization status, core service dependencies, core service startup order, configuration version number, configuration resolution results, list of available services, list of unavailable services, protocol channel initialization status, cloud connection status, and edge connection status. This basic service operation data serves as input for S2 to perform unified modeling of multi-protocol devices.

[0031] S2: Collect information on multi-protocol devices, perform unified modeling of multi-protocol device information based on service operation basic data, and generate a unified device model library containing device identifier, function identifier, protocol type and channel priority.

[0032] Specifically, after generating the basic data for service operation, multi-protocol device information is collected from device configuration data, protocol discovery results, and device registration records. The multi-protocol device information includes device identifier, device type, spatial information, protocol type, protocol address, device function information, function parameter range, online status, and last discovery time.

[0033] The protocol adapter obtains protocol discovery results through UDP broadcast, MQTT topic subscription, TCP heartbeat, RS485 polling scan, or SIP account registration detection. The default UDP broadcast discovery period is 10 seconds, which can be configured from 5 to 60 seconds. It can be appropriately extended when the number of devices increases or the network load increases, and appropriately shortened when the real-time discovery requirements increase. The default device heartbeat timeout is 60 seconds, which can be configured from 30 to 180 seconds. It is usually taken as 3 to 6 times the device reporting period in the device configuration data. If no heartbeat data or status report data is received after the device heartbeat timeout period, the online status will be updated to offline.

[0034] Available protocol channels are determined based on the protocol channel initialization status, available service list, cloud connection status, and edge connection status in the service operation basic data. When the protocol channel is successfully initialized and the core service responsible for the protocol channel is in the available service list, the protocol channel is included in the available protocol channels. For cloud channels, the cloud connection status must also be available. For edge channels, the edge connection status must also be available. For local protocol channels, a discovery response or status report data must be received within the device heartbeat timeout period.

[0035] Multi-protocol device information is mapped according to the preset unified device fields. The unified device fields include device identifier, device type, spatial information, function identifier, function parameter range, protocol type, protocol address, channel priority, online status, and status readback capability. The KNX device group address, MQTT device communication topic, TCP device server address and port, RS485 device serial port number and slave address, and SIP device account and network parameters are written into the protocol address field respectively. The device function information is converted into function identifier and function parameter range according to the function mapping relationship in the device configuration data.

[0036] After the field mapping is completed, if the device identifiers are the same, the device will be merged. If the device identifiers are missing or inconsistent, the protocol address attribution relationship in the device configuration data will be queried. If the protocol address belongs to the same device configuration record, the device type and spatial information are the same, and the device function information contains at least one identical function identifier, the device will be merged. If there is no clear attribution relationship, the device will be retained as different unified device objects. When field values ​​conflict, the device configuration data takes precedence over the device registration record, and the device registration record takes precedence over the protocol discovery result.

[0037] Channel priority can be set to level 1, level 2 or level 3, with level 1 having the highest priority. When the device configuration data includes channel priority, the configuration value is used. When the device configuration data does not include channel priority, this invention defaults to setting the local protocol channel to level 1, the edge channel to level 2, and the cloud channel to level 3. It can also be adjusted within the range of level 1 to level 3 according to the control scenario. Protocol channels of the same level are given priority to those that support status readback and have the most recent discovery time.

[0038] Based on the device merging results, a unified device object is generated. Each unified device object uses the device identifier as the primary key and records the function identifier, function parameter range, and protocol address, channel priority, online status, and status readback capability corresponding to each protocol type. A unified device model library is established based on the unified device object, and indexes are created according to device identifier, spatial information, device type, function identifier, and protocol type. The unified device model library serves as the data foundation for S3 to match target devices and target functions, generate unified control tasks, and S6 to determine target execution channels.

[0039] S3: Receives control requests from multiple sources, determines the target device and target function based on the unified device model library, and generates a unified control task that includes device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity period.

[0040] Specifically, after the unified device model library is generated, it receives control messages or trigger events, and extracts the request source type, target description information, and control target information through field parsing, event type identification, and a preset source mapping table. The source mapping table maps user interface control messages to user manual control, user-initiated scenarios to manual scenarios, device event-initiated scenarios to event-triggered scenarios, rule engine-triggered events to automated rules, security service alarms to security alarms, cloud service control messages to cloud remote control, and edge service control messages to edge local control.

[0041] The target description information includes at least one of the following: equipment identification, spatial information, and equipment type. The control target information includes functional description and target parameters. Name normalization is completed by using a preset spatial dictionary, equipment type dictionary, and function dictionary. It is assumed that "hall" and "living room" are both mapped to "living room", "lighting fixtures" and "lighting" are both mapped to "lighting equipment", and "brighten up" and "brighten up a bit" are both mapped to "brightness adjustment function".

[0042] When the target description information includes a device identifier, the target device is precisely matched using the device identifier index. If no device identifier is included, candidate devices are filtered using spatial information and device type indexes. If there are multiple candidate devices, filtering continues based on the functional description and online status. If multiple candidate devices still exist, each is identified as a target device, and a unified control task is generated for each. If no target device is matched, a target device matching failure record is generated. The functional description is mapped to a functional identifier. The existence of the functional identifier in the target device's functional identifier set is checked. After confirming that the target parameters can be converted to the data type corresponding to the functional parameter range, the target function is determined. If no match can be found, a target function matching failure record is generated.

[0043] Device identifiers, function identifiers, and protocol types are extracted from a unified device model library. When a target device corresponds to a single protocol type, that single protocol type is used directly. When a target device corresponds to multiple protocol types, the protocol type with the highest priority is selected based on available protocol channels and channel priority. Task source priority is represented by levels 1 to 4 by default, with lower values ​​indicating higher priority. Security alarms are set to level 1, user manual control and manual scenarios are set to level 2, event-triggered scenarios are set to level 3, and automation rules are set to level 4. Cloud remote control and edge local control are determined based on the permission level carried in the control message, with administrator permissions, ordinary user permissions, and guest permissions corresponding to levels 2, 3, and 4, respectively.

[0044] The effective time of a task is matched from the preset effective time configuration. The effective time of a task is calculated from the moment the unified control task is generated. This invention defaults to setting the user manual control, cloud remote control, and edge local control to 30 seconds, the manual scenario to 120 seconds, the event-triggered scenario and automation rule to 60 seconds, and the safety alarm to continue until the alarm is cleared. Except for the safety alarm, the duration can be configured within the range of 10 seconds to 300 seconds. The duration can be appropriately extended when the number of scene actions increases or the network latency increases, and appropriately shortened when the real-time control requirements increase.

[0045] The target parameters are processed through a parameter dictionary, data type conversion, and unit normalization, and then range verification is performed based on the functional parameter range. The parameter dictionary defaults to converting "on" and "on" to "on state," "off" and "off" to "off state," and "half brightness" to 50%. The brightness adjustment function parameter range defaults to 0% to 100%, and the temperature setting function parameter range defaults to 16 degrees Celsius to 30 degrees Celsius, which can be adjusted to 10 degrees Celsius to 35 degrees Celsius based on device configuration data. When the target parameter exceeds the functional parameter range, it is updated to the corresponding boundary value. If the target parameter cannot be recognized, a parameter parsing failure record is generated, and the task generation process for the current multi-source control request is stopped.

[0046] After the protocol type, task source priority, task validity time, and task target parameters are determined, the core service records the task generation time, which adopts the system time at the time of unified control task generation. The device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, task validity time, and task generation time are written into the same task data structure to generate a unified control task. The unified control task serves as the input for S4 to build task keys and perform deduplication scheduling.

[0047] S4: Construct task keys based on device identifier, function identifier and protocol type, perform deduplication scheduling on unified control tasks, and generate deduplication scheduling results.

[0048] Specifically, after generating a unified control task, the task queue partitions are set according to the protocol type. The unified control tasks corresponding to KNX, MQTT, TCP, RS485 and SIP protocols are respectively entered into the corresponding queue partitions. The device identifier, function identifier and protocol type in the unified control task are read, and the task key is formed in a fixed order of device identifier, function identifier and protocol type. This invention uses a hash index to query the same task key by default. After the hash index hits, the three fields are compared again to avoid hash collisions that cause incorrect matching.

[0049] If no duplicate task key exists in the queue of tasks to be executed, the current unified control task is written to the corresponding queue partition, and a deduplication scheduling result for the new task enqueue type is generated. If a duplicate task key exists, the task processing type is determined according to the request source type, function identifier, and task target parameter. The task processing type is matched sequentially according to the security alarm type, scene sequence type, switch status update type, and target value update type. If it matches the previous task processing type, the matching will not continue. If the request source type is a security alarm, it is determined to be a security alarm type. If the request source type is a manual scene or event-triggered scene, it is determined to be a scene sequence type. If the function identifier corresponds to a switch control function and the task target parameter is on or off, it is determined to be a switch status update type. If the function identifier corresponds to brightness, temperature, volume, or curtain opening / closing ratio and the task target parameter is a value, it is determined to be a target value update type.

[0050] The queue of tasks to be executed uses a task state machine to record the execution status. When a unified control task is written into the queue of tasks to be executed, it is updated to the state of being ready to be sent. Before S5 completes conflict coordination and S6 confirms that the task to be executed meets the conditions for allowed execution, the protocol execution thread shall not retrieve the current unified control task. When the protocol execution thread retrieves the unified control task, it is updated to the state of being sent. After the control message is sent, it is updated to the state of being sent. After receiving the execution feedback from the device, it is updated to the state of being executed.

[0051] When an existing task is in the pending state, if both tasks are security alarm types, the current unified control task will override the existing task; if only one task is a security alarm type, priority retention will be adopted, and the security alarm task will be arranged before the normal control task; if the task processing type is the scene sequence type, sequential retention will be adopted, and the tasks will be arranged according to the order in which the unified control tasks entered the queue of tasks to be executed; if the task processing type is the target value update type or the switch status update type and the request source type is the same, the current unified control task will override the existing task; if the request source types are different, both tasks will be retained and handed over to S5 for conflict coordination.

[0052] The "sending in progress," "sent," or "execution completed" statuses retrieved in S4 correspond to existing tasks that have already entered S6 in the previous scheduling cycle. When an existing task is in the "sending in progress" or "sent" status, it is not modified. Instead, a subsequent correction task is generated based on the current unified control task. The subsequent correction task is executed only after the existing task has completed execution or returned execution feedback to the device. When an existing task is in the "execution completed" status, it is removed from the queue of tasks to be executed, and the current unified control task is written into the queue of tasks to be executed as a new task.

[0053] After completing the overwrite, sequential retention, priority retention, or correction processing, the queue of tasks to be executed is updated, generating a deduplication scheduling result containing the task key, the retained unified control task, the task processing type, the existing task execution status, the processing method, and the queue update result. The task source priority and task validity time in the unified control task remain unchanged and are used as input for S5 execution conflict coordination.

[0054] S5: Based on the priority of the task source, the effective time of the task, and the preset manual protection time, the deduplication scheduling results corresponding to the same function of the same device are reconciled to generate tasks to be executed.

[0055] Specifically, after generating the deduplication scheduling results, the unified control task retained in each deduplication scheduling result is read. When the unified control task is generated by S3, the core service synchronously records the task generation time. The deduplication scheduling results are hashed and grouped according to the device identifier and function identifier to form a group of tasks to be coordinated corresponding to the same device and the same function. The protocol type is not used as a grouping condition to avoid the same physical function being executed repeatedly through different protocols.

[0056] The effective execution range is determined based on the task generation time and the task validity period. The effective execution range starts from the task generation time and ends at the sum of the task generation time and the task validity period. The effective execution range corresponding to a security alarm continues until the security alarm is cleared. When the current time exceeds the effective execution range, the deduplication scheduling result is marked as invalid. When it does not exceed the effective execution range, the tasks are sorted from high to low priority according to their source. When the source priorities are the same, the deduplication scheduling result with the earlier task generation time is given priority.

[0057] The preset manual protection time is generally 5 minutes, which can be configured within the range of 1 minute to 30 minutes. This invention defaults to setting the manual protection time for lighting equipment, HVAC equipment and curtain equipment to 3 minutes, 10 minutes and 5 minutes respectively. When no equipment type is configured, 5 minutes is used. When the equipment response inertia is large or the user needs a longer control holding time, it can be appropriately extended. When the equipment status changes rapidly, it can be appropriately shortened.

[0058] When the task group to be coordinated includes deduplication scheduling results corresponding to user manual control, the deduplication scheduling results corresponding to user manual control are arranged before the deduplication scheduling results corresponding to the automation rules. Automation rules that may constitute reverse control will be delayed in execution until user manual control is completed. After successful execution of user manual control, S6 generates a manual protection record. The manual protection record includes device identifier, function identifier, manual control target parameters, protection start time and protection end time. The protection start time is the time when user manual control is successfully executed, and the protection end time is determined according to the protection start time and the preset manual protection time. If user manual control fails to execute, no manual protection record is generated, and the delayed execution automation rules re-enter S5 for conflict coordination.

[0059] S5 reads valid manual protection records corresponding to the same function of the same device, and identifies opening and closing, and opening and closing of curtains through a preset reverse action table. For numerical control, it reads the device status cache before the user manual control occurs. When the user manual control target parameter is higher than the current device status in the device status cache and the automation rule target parameter is lower than the user manual control target parameter, or when the user manual control target parameter is lower than the current device status in the device status cache and the automation rule target parameter is higher than the user manual control target parameter, it determines that the automation rule constitutes reverse control.

[0060] The automated rules constituting reverse control do not enter the immediate execution process within the manual protection time. When the effective execution range of the task exceeds the end time of the manual protection time, it is converted to delayed execution. When the effective execution range of the task is earlier than the end time of the manual protection time, it is marked as canceled. When a security alarm conflicts with the user's manual control, the security alarm is executed first and is not limited by the manual protection time.

[0061] After completing the task source priority sorting, effective execution range judgment, and reverse control restriction, the deduplication scheduling result that is allowed to execute and ranked first is converted into an immediately executed task, and the deduplication scheduling result that is still within the effective execution range but needs to be delayed is converted into a delayed execution task. The execution condition for an immediately executed task is that the current time is within the effective execution range, and the execution condition for a delayed execution task is that the manual protection time has ended or the preceding high-priority task has been completed, while the task is still within the effective execution range. The tasks to be executed include the task key, device identifier, function identifier, protocol type, request source type, task source priority, task target parameters, execution method, execution order, effective execution range, allowed execution conditions, and conflict coordination results. The deduplication scheduling results that are invalid or canceled are only written to the conflict coordination results and not to the tasks to be executed. The tasks to be executed serve as the input for S6 to determine the target execution channel.

[0062] S6: Based on protocol type, channel priority and current network status, the target execution channel is determined from cloud channels, edge channels and local protocol channels by using channel availability filtering and priority matching methods. The task to be executed is then executed through the target execution channel, generating device status data and task execution results.

[0063] Specifically, after generating tasks to be executed, the execution method and allowed execution conditions in the tasks are read. Tasks to be executed immediately enter channel filtering if they are within the valid execution range at the current time. Tasks to be executed delayed only enter channel filtering if the allowed execution conditions are met and they are still within the valid execution range. Delayed tasks that do not meet the allowed execution conditions are retained in the task queue. When the allowed execution conditions change, they re-enter S5 for task validity and manual protection verification. After being re-determined as tasks to be executed immediately by S5, they enter S6. If they exceed the valid execution range, they are updated to be invalid. The current network status is obtained through the operating system network interface, connection status callback, and periodic probes. The current network status includes the cloud network status and the LAN status. In this embodiment, an unavailable cloud network status is recorded as network unavailable. When the LAN is available, edge channels or local protocol channels are still allowed to execute control. The channel status is updated through MQTT connection listening, TCP heartbeat, KNX interface detection, RS485 port detection, SIP registration detection, and sending receipts. The channel status includes normal connection, abnormal connection, authentication failure, sending timeout, and unavailable.

[0064] The default channel heartbeat detection period is 10 seconds, which can be configured from 5 to 60 seconds. The default channel timeout period is 30 seconds, which can be configured from 10 to 120 seconds. The channel timeout period is generally no less than two channel heartbeat detection periods. When the network response requirements are high, the channel heartbeat detection period can be appropriately shortened. When the network load is high, it can be appropriately extended. If no heartbeat response or receipt is received after the channel timeout period, the channel status will be updated to connection abnormal.

[0065] Read the device identifier, function identifier, and protocol type from the task to be executed. Query the protocol address and channel priority from the unified device model library. Then, filter candidate execution channels that support the corresponding protocol type and have protocol address mapping from cloud channels, edge channels, and local protocol channels. When the protocol type is KNX or RS485, the local protocol channel or the edge channel with protocol forwarding capability can be used as a candidate execution channel. When the protocol type is MQTT, TCP, or SIP, the cloud channel, edge channel, or local protocol channel is included in the candidate execution channels according to the protocol adapter configuration.

[0066] A candidate execution channel is determined to be an available execution channel when it is in a normal connection state, has valid authentication, has not exceeded the channel timeout period, and the current network status supports communication. For cloud channels, the cloud network status must be available; for edge channels, the local area network status must be available; and for local protocol channels, the local area network interface or protocol interface must be in a normal state. If no available execution channel exists, a task execution result of type "channel unavailable" is generated. If the pending task is still within the valid execution range, it is retained until the channel status recovers; if it exceeds the valid execution range, it is updated to execution failure. When the channel status recovers from connection error or unavailable to normal connection, the retained pending task is triggered to re-enter S6 via a channel status change event.

[0067] When multiple available execution channels exist, the highest priority available execution channel is selected according to the channel priority in the unified device model library. When the channel priorities are the same, the available execution channel that supports status readback and has the most recent discovery time is selected first. If the target execution channel returns a failure before the control data is sent, the system switches to the next available execution channel. If the control data has been sent but the feedback timeout occurs, the system first queries the device status. If the device status meets the task target parameters, the execution is considered successful. If the device status does not meet the task target parameters, the system switches the channel. If the device status cannot be confirmed, it is marked as pending confirmation to avoid resending control data.

[0068] After determining the target execution channel, the task to be executed is converted into corresponding protocol control data. The KNX protocol generates control messages based on the device group address and data point type, the MQTT protocol generates publication messages based on the device communication topic and task target parameters, the TCP protocol generates control data based on the protocol address, function identifier, and task target parameters, the RS485 protocol generates control frames based on the port number, slave address, and task target parameters, and the SIP protocol generates control requests based on the device account and session parameters. The protocol control data is then sent through the target execution channel.

[0069] Device status data and task execution results are generated based on the sent receipt, device status readback data, or device status reported data. Device status data includes device identifier, function identifier, task target parameters, device feedback status, status update time, and status trust identifier. Task execution results include task key, target execution channel, sending result, feedback result, failure reason, and offline execution identifier. If the target device supports status readback, the status trust identifier is updated to "confirmed." If it does not support status readback, the task target parameters are recorded as "pending confirmation," and confirmation is subsequently completed based on the device status reported data. When the network is unavailable, tasks completed via edge channel or local protocol channel are written to the offline execution identifier, which serves as input for S7 to generate offline operation logs. When the request source type is user-manually controlled and the task execution is successful, a manual protection record is generated, with the protection start time using the device execution feedback time. If the target device does not support status readback but the sent receipt indicates successful sending, the protection start time uses the sent receipt time. No manual protection record is generated when the task execution fails.

[0070] S7: Generates a status version based on device status data, updates the device status cache, records offline operation logs containing the status version when the network is unavailable, and performs cloud-edge status synchronization based on the offline operation logs and status version when the network is restored.

[0071] Specifically, after generating device status data and task execution results, if the task execution result is a failure and no valid device status data is generated, no new status version is generated. When the current network status is unavailable, the offline operation log records the latest status version in the device status cache. If the corresponding status version does not exist in the device status cache, a "no valid status version" flag is written. The "no valid status version" flag only indicates that the task execution failed and is not included in the cloud-edge status version comparison. The execution failure record does not update the cloud device status. When there is valid readback data for the device feedback status, the device feedback status is used as the current device status, and the status trust identifier is updated to "confirmed." When there is a lack of valid readback data for the device feedback status, the task target parameter is used as the current device status, and the status trust identifier is updated to "pending confirmation." A confirmed status is generated again when device status reporting data is received subsequently.

[0072] The status version consists of the status update time, the node increment sequence number, and the version source identifier. The device identifier and function identifier jointly determine the status record. The node increment sequence number starts from 1 by default and increases by 1 with each status update for the same device and the same function. Cloud nodes and edge nodes use the same status version structure. When comparing, the status update time, node increment sequence number, and version source identifier are compared in sequence to determine the order of the status versions. The status update time uses the system time calibrated according to the network time protocol. The calibration cycle is 10 minutes by default, which can be configured within the range of 1 minute to 60 minutes. It can be appropriately shortened when the time consistency requirement is high, and appropriately extended when the network communication load is high. When the network is unavailable, the local system time after the most recent calibration is used. Before generating the status version, the new status update time is compared with the status update time in the device status cache. If the new status update time is not later than the cached status update time, the cached status update time plus 1 millisecond is used as the new status update time, ensuring that the status update time corresponding to the same device and the same function increases monotonically.

[0073] The device status cache uses the device identifier and function identifier as indexes to record the current device status, status version, status trust identifier, and status update time. When the device status cache does not have a corresponding record, a new record is added. When the newly generated status version is later than the cached status version, the device status cache is updated. When the newly generated status version is earlier than the cached status version, the original record is retained, and the reason for state discarding is written. If the newly generated status version is the same as the cached status version and the current device status is the same, it is not updated again. If the newly generated status version is the same as the cached status version but the current device status is different, a status conflict record is generated.

[0074] When the current network status is unavailable, offline operation logs are generated based on the tasks to be executed, task execution results, and status versions. Offline operation logs include log identifier, device identifier, function identifier, protocol type, request source type, task source priority, task target parameters, task execution result, execution time, status version, status trust identifier, and synchronization status. Synchronization status includes not synchronized, synchronizing, synchronized, synchronization failed, and pending confirmation. Offline operation logs are stored in a local database by default. The retention period for synchronized offline operation logs is generally 7 days, configurable within the range of 1 to 30 days. The maximum number of entries in a single offline operation log partition is 10,000 by default, adjustable from 1,000 to 100,000 depending on local storage capacity. When the maximum number of entries is exceeded, the earliest generated synchronized logs are cleaned up first; unsynchronized logs are not automatically deleted and are retained until synchronization is complete or manual archiving is performed. If the maximum number of entries is still reached after cleaning up synchronized logs, a new backup log partition is created and a local storage exception record is generated; unsynchronized logs are not deleted.

[0075] When the current network status is restored to availability, after reading the offline operation logs with a synchronization status of unsynchronized or failed, first identify those without a valid status version identifier. Offline operation logs containing no valid status version identifier only synchronize task failure records and do not participate in status version sorting and status consistency processing. After the task failure records are synchronized, update the synchronization status to synchronized. Group by device identifier and function identifier, and then sort by status version from earliest to latest. Obtain cloud device status, cloud status version, request source type, task source priority, and status trust identifier through the cloud status query interface. If cloud status acquisition fails, update the synchronization status to synchronize failed. When the current network status remains available, the next synchronization process is triggered by the S6 channel heartbeat detection event.

[0076] When performing state consistency processing, if the trusted state identifiers of offline device state and cloud device state are different, the confirmed state takes precedence over the unconfirmed state. If the trusted state identifiers are the same, the state corresponding to a security alarm takes precedence over a normal control state. If both are normal control states, the final device state is determined according to the task source priority, with the state having the lower task source priority value taking precedence. If the task source priorities are the same, the later state version is used. If the state versions are the same but the device states are different, a user confirmation task is generated. If the user confirmation task is not completed, the synchronization status of the cloud-edge state synchronization result and the corresponding offline operation log is updated to "unconfirmed," and neither the device state cache nor the cloud device state is overwritten. After the user confirmation task is completed, the final device state is determined based on the user confirmation result, and cloud-edge state synchronization is re-executed. If the task corresponding to the offline operation log fails to execute, the offline device state is not used to update the cloud device state, and the unconfirmed offline device state does not overwrite the confirmed cloud device state.

[0077] When the offline device status is determined to be the final device status, the offline device status and status version are uploaded to the cloud; when the cloud device status is determined to be the final device status, the device status cache is updated according to the cloud device status. After processing is completed, a cloud-edge status synchronization result is generated, which includes the synchronization direction, final device status, final status version, conflict handling method, and synchronization status. Offline operation logs that successfully synchronize are updated to "synchronized," while offline operation logs that fail to synchronize are retained as "synchronization failed."

[0078] Example 2: Please refer to Figure 2 This exemplary IoT core control system based on multi-protocol fusion includes: Service initialization module: Initializes core services and parses device configuration to generate basic data for service operation; Unified Device Modeling Module: Collects information on devices with multiple protocols, performs unified modeling on the information on devices with multiple protocols based on service operation data, and generates a unified device model library that includes device identifier, function identifier, protocol type and channel priority; Control task generation module: Receives control requests from multiple sources, determines the target device and target function based on the unified device model library, and generates a unified control task that includes device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity period; Task deduplication and scheduling module: Constructs task keys based on device identifier, function identifier and protocol type, performs deduplication and scheduling of unified control tasks, and generates deduplication and scheduling results; Task conflict coordination module: Based on task source priority, task validity time, and preset manual protection time, it coordinates the conflict of deduplication scheduling results corresponding to the same function of the same device and generates tasks to be executed. Channel selection and execution module: Based on protocol type, channel priority and current network status, it uses channel availability filtering and priority matching methods to determine the target execution channel from cloud channels, edge channels and local protocol channels, and executes the task to be executed through the target execution channel, generating device status data and task execution results; State synchronization closed-loop module: Generates state version based on device state data, updates device state cache, records offline operation logs containing state version when the network is unavailable, and performs cloud-edge state synchronization based on offline operation logs and state version when the network is restored.

[0079] It should be noted that the IoT core control system based on multi-protocol fusion provided in the above embodiments and the IoT core control method based on multi-protocol fusion provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the IoT core control system based on multi-protocol fusion provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above, and this is not a limitation here.

[0080] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A core control method for the Internet of Things based on multi-protocol fusion, characterized in that, include: S1: Initialize core services and parse device configuration to generate basic data for service operation; S2: Collect information on multi-protocol devices, perform unified modeling of multi-protocol device information based on service operation basic data, and generate a unified device model library containing device identifier, function identifier, protocol type and channel priority; S3: Receive control requests from multiple sources, determine the target device and target function based on the unified device model library, and generate a unified control task that includes device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity time; S4: Construct task keys based on device identifier, function identifier and protocol type, perform deduplication scheduling on unified control tasks, and generate deduplication scheduling results; S5: Based on the priority of the task source, the effective time of the task, and the preset manual protection time, the deduplication scheduling results corresponding to the same function of the same device are reconciled to generate tasks to be executed. S6: Based on protocol type, channel priority and current network status, the target execution channel is determined from cloud channels, edge channels and local protocol channels by using channel availability filtering and priority matching methods. The task to be executed is then executed through the target execution channel, generating device status data and task execution results. S7: Generates a status version based on device status data, updates the device status cache, records offline operation logs containing the status version when the network is unavailable, and performs cloud-edge status synchronization based on the offline operation logs and status version when the network is restored.

2. The core control method for the Internet of Things based on multi-protocol fusion according to claim 1, characterized in that, S1 includes: Read service registration data and device configuration data, and determine the startup order and dependencies of core services based on the service registration data; Initialize core services according to startup order and dependencies, parse device configuration data, and obtain configuration parsing results; Generate basic data for service operation based on the initialization status and configuration parsing results of core services.

3. The IoT core control method based on multi-protocol fusion according to claim 1, characterized in that, S2 include: Collect multi-protocol device information from device configuration, protocol discovery, and device registration records; Based on service operation data, determine the available protocol channels corresponding to multi-protocol device information; The multi-protocol device information is mapped according to the preset unified device fields. Based on the device identifier, the protocol address corresponding to the available protocol channel and the device function information configured by the device, the multi-protocol device information corresponding to the same physical device is merged to generate a unified device object. A unified device model library is generated based on the unified device object.

4. The core control method for the Internet of Things based on multi-protocol fusion according to claim 1, characterized in that, Determining target devices and target functions based on a unified device model library includes: Parse control requests from multiple sources to obtain request source type, target description information, and control target information. The request source type includes: user manual control, manual scenario, event-triggered scenario, automation rule, security alarm, cloud remote control, and edge local control. The target description information includes at least one of device identifier, spatial information, and device type. The control target information includes: function description and target parameters. The target device is matched in the unified device model library based on the target description information, and the target function is determined based on the function identifier and function parameter range corresponding to the target device.

5. The core control method for the Internet of Things based on multi-protocol fusion according to claim 4, characterized in that, Generating unified control tasks includes: Based on the target device and target function, extract the device identifier, function identifier, and protocol type from the unified device model library; The task source priority is determined based on the request source type and preset source priority rules. The preset source priority rules include: security alarms are higher than user manual control and manual scenarios; user manual control and manual scenarios are higher than event-triggered scenarios; event-triggered scenarios are higher than automation rules; and cloud remote control and edge local control are determined according to preset permission levels. Based on the request source type of the multi-source control request, the task validity time is matched from the preset task validity time configuration; Based on the target parameters in the control target information and the range of functional parameters corresponding to the target equipment, the parameter parsing and range verification method is used to determine the task target parameters. A unified control task is generated based on device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity period.

6. The core control method for the Internet of Things based on multi-protocol fusion according to claim 1, characterized in that, S4 includes: Construct a task key using the device identifier, function identifier, and protocol type in the unified control task, and query whether there is an existing task with the same task key in the queue of tasks to be executed; If no task already exists, the current unified control task is written into the task queue to be executed. When an existing task exists, the task processing type is determined based on the function identifier, task target parameters, and request source type. The task processing type includes target value update type, switch status update type, scene sequence type, and security alarm type. Based on the task processing type and the execution status of existing tasks, the system performs overwrite, sequential retention, priority retention, or correction processing on the current unified control task and existing tasks, updates the queue of tasks to be executed, and generates deduplication scheduling results.

7. The IoT core control method based on multi-protocol fusion according to claim 1, characterized in that, S5 include: Identify multiple deduplication scheduling results corresponding to the same device and the same function based on device identifier and function identifier; The execution order of multiple deduplication scheduling results is determined based on the priority of the task source, and the effective execution range of multiple deduplication scheduling results is determined based on the effective time of the task. When multiple deduplication scheduling results include deduplication scheduling results corresponding to user manual control, the deduplication scheduling results corresponding to the automation rules are restricted from performing reverse control on the same device and the same function within the preset manual protection time. Tasks to be executed are generated based on the execution order, effective execution scope, and reverse control constraints.

8. The IoT core control method based on multi-protocol fusion according to claim 1, characterized in that, S6 include: Obtain the current network status and the channel status of cloud channels, edge channels, and local protocol channels; Based on the protocol type in the task to be executed, candidate execution channels are selected from cloud channels, edge channels, and local protocol channels; Based on the channel status of candidate execution channels, channel availability is filtered to obtain available execution channels; Based on the channel priority in the unified device model library, the target execution channel is determined from the available execution channels; The task to be executed is executed through the target execution channel, and the device status data and task execution results are generated based on the execution feedback returned by the target execution channel.

9. The core control method for the Internet of Things based on multi-protocol fusion according to claim 1, characterized in that, S7 includes: A status version is generated based on the device status data, and the device status cache is updated by combining the device status data and the status version. When the current network status is unavailable, generate an offline operation log containing the status version based on the task to be executed, the task execution result, and the status version; When the current network status recovers from unavailable to available, read the offline operation log and obtain the status version corresponding to the cloud device status; Based on the status version in the offline operation log and the corresponding status version of the cloud device, status consistency processing is performed to generate cloud-edge status synchronization results. Update the device status cache and cloud device status based on the cloud-edge status synchronization results.

10. A core control system for the Internet of Things (IoT) based on multi-protocol fusion, used to implement the core control method for the Internet of Things based on multi-protocol fusion as described in any one of claims 1-9, characterized in that, include: Service initialization module: Initializes core services and parses device configurations to generate basic data for service operation; Unified Device Modeling Module: Collects information on devices with multiple protocols, performs unified modeling on the information on devices with multiple protocols based on service operation data, and generates a unified device model library that includes device identifier, function identifier, protocol type and channel priority; Control task generation module: Receives control requests from multiple sources, determines the target device and target function based on the unified device model library, and generates a unified control task that includes device identifier, function identifier, protocol type, request source type, task target parameters, task source priority, and task validity period; Task deduplication and scheduling module: Constructs task keys based on device identifier, function identifier and protocol type, performs deduplication and scheduling on unified control tasks, and generates deduplication and scheduling results; Task conflict coordination module: Based on task source priority, task validity time, and preset manual protection time, it coordinates the conflict of deduplication scheduling results corresponding to the same function of the same device and generates tasks to be executed. Channel selection and execution module: Based on protocol type, channel priority and current network status, it uses channel availability filtering and priority matching methods to determine the target execution channel from cloud channels, edge channels and local protocol channels, and executes the task to be executed through the target execution channel, generating device status data and task execution results; State synchronization closed-loop module: Generates state version based on device state data, updates device state cache, records offline operation logs containing state version when the network is unavailable, and performs cloud-edge state synchronization based on offline operation logs and state version when the network is restored.

Images