A multi-subscriber station security state synchronization method based on an OpenHarmony distributed data service

Abstract

The application discloses a kind of multi-substation security state synchronization methods based on OpenHarmony distributed data service, comprising the following steps: S1: distributed database initialization.The application realizes multi-substation security state synchronization based on OpenHarmony distributed data service, replaces traditional polling with push type automatic synchronization, significantly reduces synchronization delay, improves real-time performance, adopts decentralized architecture without central server forwarding, avoids server load too high and single point failure risk, and relies on system native capability to automatically complete message confirmation, retransmission and deduplication, significantly reduces application layer development complexity, avoids synchronization inconsistency problem, simultaneously through the conflict resolution mechanism of timestamp and main substation priority, effectively handle multi-substation concurrent operation conflict, guarantee the eventual consistency of security state data, overall realize low delay, high reliability, low cost, strong consistency multi-substation security state real-time synchronization.

Description

Technical Field

[0001] This invention relates to the field of intelligent building intercom technology, and in particular to a method for synchronizing the security status of multiple intercom units based on OpenHarmony distributed data service. Background Technology

[0002] In intelligent building intercom systems, a household typically installs multiple extension devices, including a main extension and several sub-extensions. These extension devices need to synchronously share security status information, including arming / disarming status, security status of each zone, alarm information, etc. Traditional synchronization methods have the following shortcomings: 1. Traditional polling synchronization method: The status of the extensions is synchronized by polling at regular intervals, which has the problems of high latency and poor real-time performance. When the main extension changes the arming status, the secondary extension may need several seconds or even longer to detect the change. 2. Central server forwarding method: All state changes are forwarded through a central server, which increases the server load and will cause the entire system to crash if the server fails. At the same time, this method also increases network latency. 3. Message broadcasting method: broadcast state change messages via UDP or MQTT, but the application layer needs to implement complex logic such as message confirmation, retransmission, and deduplication, which has high development costs and is prone to synchronization inconsistency problems; 4. Data consistency issues: In scenarios where multiple machines operate simultaneously, data conflicts are prone to occur, and traditional solutions cannot guarantee eventual data consistency. In summary, this application proposes a method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data services. Summary of the Invention

[0003] Based on the technical problems existing in the background technology, this invention proposes a multi-dedicated security status synchronization method based on OpenHarmony distributed data service.

[0004] This invention proposes a method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service, comprising the following steps: S1: Distributed Database Initialization: Start the HarmonyOS extension of the building intercom and complete the distributed key-value database initialization on each extension device, configuring the database identifier, automatic synchronization mode, push mode, security level and database type; S2: Security Status Data Structure Definition: Defines a unified security status data structure that includes arming mode, zone status array, delayed arming information, operating device identifier, timestamp field, and extended fields; S3: Status Change Monitoring and Broadcasting: When the security status of any device changes, the local data is updated and written to the distributed database. The system automatically pushes and synchronizes the data and completes the confirmation, retry and local status persistence. S4: Data Change Reception and Processing: Other extension devices receive synchronized data through the registered data change listener, perform parsing and conflict detection, and update the local status, refresh the UI and play voice prompts after the conflict is resolved, and persist the data locally. S5: Conflict detection and resolution mechanism: When multiple extension devices are modified concurrently, conflict detection and resolution are completed based on the timestamp "last write wins" and the master extension priority strategy to ensure the eventual consistency of data across multiple extension devices.

[0005] Preferably, in step S1, the database identifier is a unique database identifier assigned to the security status data to ensure that different types of data are isolated from each other; When the autoSync parameter is set to true in automatic synchronization mode, the automatic synchronization function of the distributed data service is enabled. When local data changes, the changes will be automatically synchronized to other devices in the same distributed network without the application layer having to actively trigger the synchronization operation. In push mode, when data changes, the system will actively push the changes to other devices, achieving millisecond-level synchronization latency. Compared with pull mode, push mode has lower latency and better real-time performance. The security level is device-level encryption, ensuring that security status data is encrypted end-to-end during transmission to prevent data from being stolen or tampered with; Select a single-version database as the database type to ensure that all devices see the same data and avoid data version confusion.

[0006] Preferably, in S2, the arming mode is used to represent the current security arming status, and the specific values ​​include: disarming mode, with a value of 0, indicating that all defense zones are de-monitored; out-of-home arming mode, with a value of 1, indicating that all defense zones are monitored; home arming mode, with a value of 2, indicating that some defense zones are monitored; and sleeping arming mode, with a value of 3, indicating that defense zones outside the bedroom are monitored. The zone status array is used to store detailed status information for each zone. Each zone status includes: zone identifier, used to uniquely identify the zone; zone arming status, indicating whether the zone is under monitoring; sensor type, used to identify the type of sensor connected to the zone, including door and window sensors, infrared sensors, and smoke sensors; sensor current status, used to indicate the current status detected by the sensor; and zone operating mode, used to identify the operating mode of the zone, including normally open mode and normally closed mode. Delayed arming information is used to support the arming delay function, including: delay time, which is the number of seconds for arming delay set by the user; remaining delay time, which is the number of seconds remaining before arming takes effect. The arming delay function allows users to have a buffer period after leaving the system, avoiding false alarms during the arming process. The operating device identifier is used to record the device identifier that last modified the security status. This field plays an important role in conflict detection and can identify the source device of the data change. The timestamp field records the last time the data was modified, accurate to the millisecond level. The timestamp is a key basis for conflict detection and resolution, used to determine the order of multiple concurrent changes. The extended fields are reserved for storing alarm records and device status information, and have good scalability.

[0007] Preferably, the specific logical steps of S3 are as follows: S301: Local Data Update: First, update the local security status data, including modifying the corresponding field values. The system will automatically update the timestamp field to the current time and update the operating device identifier to the unique identifier of this device. S302: Write to distributed database: Write the updated complete security status data to the distributed key-value database. Since the database is configured with automatic synchronization mode, the write operation will trigger the synchronization mechanism of the distributed data service. S303: Automatic Data Push: After the distributed data service detects a data change, it automatically pushes the changed data to all other extension devices in the same distributed network through the SYNC_MODE_PUSH push mode. The push process is completed by the underlying operating system, and the application layer does not need to care about the network transmission details. S304: Push confirmation mechanism: The distributed data service has a built-in push confirmation mechanism to ensure that data is successfully delivered to the target device. If the push fails, it will automatically retry to ensure reliable data transmission. S305: Local State Persistence: Updated data is simultaneously persisted to local storage, ensuring that the latest security state can be restored after the device restarts.

[0008] Preferably, the specific logical steps of S4 are as follows: S401: Listener Registration: When the application starts, register a data change listener with the distributed database. Set the listener type to DATA_CHANGED to indicate that it listens for all data change events. S402: Change Event Reception: When a data change notification is received, the system calls back the listener and passes the change notification object. The change notification object contains the type of change and the specific data content of the change. The types of changes include addition, update and deletion. S403: Data Parsing: Extract security status data from the change notification, parse the JSON format data content, and restore the data content to a security status data structure object; S404: Conflict Detection: Compare the timestamps of the received data with those of the local data to determine if there is a conflict. If the timestamps are the same but the source devices are different, it indicates that there is a concurrent modification conflict. S405: Conflict resolution: If a conflict is detected, the conflict resolution mechanism is invoked for processing. The "last write wins" strategy is adopted, with the data with the larger timestamp taking precedence. If the timestamps are the same, the data from the main machine and the extension machine takes precedence. S406: Local Status Update: Updates the synchronized security status data to the local machine, and triggers a UI refresh to update and display the current arming status and the status of each defense zone. S407: Voice prompts: Play corresponding voice prompts according to the type of status change, including: play "arming successful" prompt when arming is successful, play "disarming successful" prompt when disarming is successful, and play "arming delayed" prompt at regular intervals when arming is delayed. S408: Local Persistence: Persist synchronized data to local storage to ensure that the device can be restored to the correct state after a restart.

[0009] Preferably, the specific logical steps of S5 are as follows: S501: Conflict detection conditions: When two devices modify the same data almost simultaneously and the difference in the timestamps of the modifications is within a preset threshold, a conflict is determined. S502: Timestamp comparison strategy: The "last write wins" strategy is adopted. The timestamps of two changes are compared and the change with the larger timestamp is taken as the final result to ensure the eventual consistency of the data. S503: Device Priority Strategy: When two changes have the same timestamp or a very small difference, the device priority strategy is used to resolve the conflict. The primary extension has a higher priority, and its changes take precedence over the changes of the secondary extension. S504: Built-in mechanism of distributed data service: OpenHarmony distributed data service itself also has a built-in conflict resolution mechanism, which can guarantee the eventual consistency of data at the system level and further enhance the reliability of the system. S505: Conflict Resolution Notification: After the conflict is resolved, the system will send a final result notification to all relevant devices to ensure that all devices eventually reach a consistent state.

[0010] Preferably, in step S501, the threshold is configured by the system default or set by the user.

[0011] Compared with existing technologies, the beneficial effects of this invention are: 1. Push-based automatic synchronization replaces traditional polling, eliminating polling waiting delays and achieving millisecond-level low-latency synchronization of security status, significantly improving the real-time performance of status synchronization; 2. It adopts a decentralized distributed synchronization architecture, eliminating the need for a central server for forwarding, reducing server load, avoiding system paralysis caused by single points of failure, and reducing network transmission latency. 3. Relying on the native capabilities of OpenHarmony distributed data services, message confirmation, retransmission, and deduplication are automatically completed without the need for complex logic development at the application layer, reducing development costs and avoiding synchronization inconsistency issues; 4. By incorporating a conflict detection and resolution mechanism based on timestamps and master / slave priorities, coupled with underlying system consistency guarantees, data conflicts arising from concurrent operations of multiple slave devices are effectively resolved, ensuring eventual consistency of security status. This invention achieves multi-device security status synchronization based on OpenHarmony distributed data service. It adopts push-based automatic synchronization instead of traditional polling, significantly reducing synchronization latency and improving real-time performance. The decentralized architecture eliminates the need for a central server for forwarding, avoiding the risk of excessive server load and single point of failure. Furthermore, it automatically completes message confirmation, retransmission, and deduplication based on the system's native capabilities, greatly reducing the complexity of application layer development and avoiding synchronization inconsistency issues. At the same time, through the conflict resolution mechanism of timestamps and master / delegation priorities, it effectively handles conflicts in concurrent operations of multiple delegations, ensuring the eventual consistency of security status data. Overall, it achieves low-latency, high-reliability, low-cost, and highly consistent real-time synchronization of multi-device security status. Attached Figure Description

[0012] Fig. 1 This is a flowchart summarizing a multi-dedicated security status synchronization method based on OpenHarmony distributed data service proposed in this invention. Fig. 2 This is a detailed flowchart of a multi-device security status synchronization method based on OpenHarmony distributed data service proposed in this invention. Detailed Implementation

[0013] The present invention will be further explained below with reference to specific embodiments. Example

[0014] Reference Figs. 1-2 This embodiment proposes a method for synchronizing the security status of multiple extensions based on OpenHarmony distributed data services, including the following steps: S1: Distributed Database Initialization: Start the HarmonyOS extension of the building intercom and complete the distributed key-value database initialization on each extension device, configuring the database identifier, automatic synchronization mode, push mode, security level and database type; The database identifier is a unique database identifier assigned to security status data to ensure that different types of data are isolated from each other; When the autoSync parameter is set to true in automatic synchronization mode, the automatic synchronization function of the distributed data service is enabled. When local data changes, the changes will be automatically synchronized to other devices in the same distributed network without the application layer having to actively trigger the synchronization operation. In push mode, when data changes, the system will actively push the changes to other devices, achieving millisecond-level synchronization latency. Compared with pull mode, push mode has lower latency and better real-time performance. The security level is device-level encryption, ensuring that security status data is encrypted end-to-end during transmission to prevent data from being stolen or tampered with; Select a single-version database type to ensure that all devices see the same data and avoid data version confusion. S2: Security Status Data Structure Definition: Defines a unified security status data structure that includes arming mode, zone status array, delayed arming information, operating device identifier, timestamp field, and extended fields; The arming mode is used to indicate the current security arming status. Specific values ​​include: disarm mode (value 0), which means all zones are disarmed; out-of-home arming mode (value 1), which means all zones are monitored; home arming mode (value 2), which means some zones are monitored; and bedtime arming mode (value 3), which means zones outside the bedroom are monitored. The zone status array is used to store detailed status information for each zone. Each zone status includes: zone identifier, used to uniquely identify the zone; zone arming status, indicating whether the zone is under monitoring; sensor type, used to identify the type of sensor connected to the zone, including door and window sensors, infrared sensors, and smoke sensors; sensor current status, used to indicate the current status detected by the sensor; and zone operating mode, used to identify the operating mode of the zone, including normally open mode and normally closed mode. Delayed arming information is used to support the arming delay function, including: delay time, which is the number of seconds for arming delay set by the user; remaining delay time, which is the number of seconds remaining before arming takes effect. The arming delay function allows users to have a buffer period after leaving the system, avoiding false alarms during the arming process. The operating device identifier is used to record the device identifier that last modified the security status. This field plays an important role in conflict detection and can identify the source device of the data change. The timestamp field records the last time the data was modified, accurate to the millisecond level. The timestamp is a key basis for conflict detection and resolution, used to determine the order of multiple concurrent changes. The extended fields are reserved for storing alarm records and device status information, and have good scalability; S3: Status Change Monitoring and Broadcasting: When the security status of any device changes, the local data is updated and written to the distributed database. The system automatically pushes and synchronizes the data and completes the confirmation, retry and local status persistence. The specific logical steps are as follows: S301: Local Data Update: First, update the local security status data, including modifying the corresponding field values. The system will automatically update the timestamp field to the current time and update the operating device identifier to the unique identifier of this device. S302: Write to distributed database: Write the updated complete security status data to the distributed key-value database. Since the database is configured with automatic synchronization mode, the write operation will trigger the synchronization mechanism of the distributed data service. S303: Automatic Data Push: After the distributed data service detects a data change, it automatically pushes the changed data to all other extension devices in the same distributed network through the SYNC_MODE_PUSH push mode. The push process is completed by the underlying operating system, and the application layer does not need to care about the network transmission details. S304: Push confirmation mechanism: The distributed data service has a built-in push confirmation mechanism to ensure that data is successfully delivered to the target device. If the push fails, it will automatically retry to ensure reliable data transmission. S305: Local State Persistence: Updated data is simultaneously persisted to local storage to ensure that the latest security state can be restored after the device restarts; S4: Data Change Reception and Processing: Other extension devices receive synchronized data through the registered data change listener, perform parsing and conflict detection, and update the local status, refresh the UI and play voice prompts after the conflict is resolved, and persist the data locally. The specific logical steps are as follows: S401: Listener Registration: When the application starts, register a data change listener with the distributed database. Set the listener type to DATA_CHANGED to indicate that it listens for all data change events. S402: Change Event Reception: When a data change notification is received, the system calls back the listener and passes the change notification object. The change notification object contains the type of change and the specific data content of the change. The types of changes include addition, update and deletion. S403: Data Parsing: Extract security status data from the change notification, parse the JSON format data content, and restore the data content to a security status data structure object; S404: Conflict Detection: Compare the timestamps of the received data with those of the local data to determine if there is a conflict. If the timestamps are the same but the source devices are different, it indicates that there is a concurrent modification conflict. S405: Conflict resolution: If a conflict is detected, the conflict resolution mechanism is invoked for processing. The "last write wins" strategy is adopted, with the data with the larger timestamp taking precedence. If the timestamps are the same, the data from the main machine and the extension machine takes precedence. S406: Local Status Update: Updates the synchronized security status data to the local machine, and triggers a UI refresh to update and display the current arming status and the status of each defense zone. S407: Voice prompts: Play corresponding voice prompts according to the type of status change, including: play "arming successful" prompt when arming is successful, play "disarming successful" prompt when disarming is successful, and play "arming delayed" prompt at regular intervals when arming is delayed. S408: Local Persistence: Persist synchronized data to local storage to ensure that the device can be restored to the correct state after a restart; S5: Conflict detection and resolution mechanism: When multiple extension devices are modified concurrently, conflict detection and resolution are completed based on the timestamp "last write wins" and the master extension priority strategy to ensure the eventual consistency of data across multiple extension devices; The specific logical steps are as follows: S501: Conflict detection conditions: When two devices modify the same data almost simultaneously and the difference in the timestamps of the modifications is within a preset threshold, a conflict is determined. The threshold is configured by the system default or set by the user. S502: Timestamp comparison strategy: The "last write wins" strategy is adopted. The timestamps of two changes are compared and the change with the larger timestamp is taken as the final result to ensure the eventual consistency of the data. S503: Device Priority Strategy: When two changes have the same timestamp or a very small difference, the device priority strategy is used to resolve the conflict. The primary extension has a higher priority, and its changes take precedence over the changes of the secondary extension. S504: Built-in mechanism of distributed data service: OpenHarmony distributed data service itself also has a built-in conflict resolution mechanism, which can guarantee the eventual consistency of data at the system level and further enhance the reliability of the system. S505: Conflict Resolution Notification: After the conflict is resolved, the system will send a final result notification to all relevant devices to ensure that all devices eventually reach a consistent state; This embodiment uses OpenHarmony distributed data service to achieve multi-device security status synchronization. It adopts push-based automatic synchronization instead of traditional polling, which significantly reduces synchronization latency and improves real-time performance. The decentralized architecture eliminates the need for a central server to forward data, avoiding the risk of excessive server load and single point of failure. Furthermore, it automatically completes message confirmation, retransmission, and deduplication based on the system's native capabilities, greatly reducing the complexity of application layer development and avoiding synchronization inconsistency issues. At the same time, through the conflict resolution mechanism of timestamps and master / delegation priorities, it effectively handles conflicts in concurrent operations of multiple delegations, ensuring the eventual consistency of security status data. Overall, it achieves low latency, high reliability, low cost, and strong consistency in real-time synchronization of multi-device security status.

[0015] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service, characterized in that, Includes the following steps: S1: Distributed Database Initialization: Start the HarmonyOS extension of the building intercom and complete the distributed key-value database initialization on each extension device, configuring the database identifier, automatic synchronization mode, push mode, security level and database type; S2: Security Status Data Structure Definition: Defines a unified security status data structure that includes arming mode, zone status array, delayed arming information, operating device identifier, timestamp field, and extended fields; S3: Status Change Monitoring and Broadcasting: When the security status of any device changes, the local data is updated and written to the distributed database. The system automatically pushes and synchronizes the data and completes the confirmation, retry and local status persistence. S4: Data Change Reception and Processing: Other extension devices receive synchronized data through the registered data change listener, perform parsing and conflict detection, and update the local status, refresh the UI and play voice prompts after the conflict is resolved, and persist the data locally. S5: Conflict detection and resolution mechanism: When multiple extension devices are modified concurrently, conflict detection and resolution are completed based on the timestamp "last write wins" and the master extension priority strategy to ensure the eventual consistency of data across multiple extension devices.

2. The method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service according to claim 1, characterized in that, In S1, the database identifier is a unique database identifier assigned to the security status data to ensure that different types of data are isolated from each other. When the autoSync parameter is set to true in automatic synchronization mode, the automatic synchronization function of the distributed data service is enabled. When local data changes, the changes will be automatically synchronized to other devices in the same distributed network without the application layer having to actively trigger the synchronization operation. In push mode, when data changes, the system will actively push the changes to other devices, achieving millisecond-level synchronization latency. Compared with pull mode, push mode has lower latency and better real-time performance. The security level is device-level encryption, ensuring that security status data is encrypted end-to-end during transmission to prevent data from being stolen or tampered with; Select a single-version database as the database type to ensure that all devices see the same data and avoid data version confusion.

3. The method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service according to claim 2, characterized in that, In S2, the arming mode is used to indicate the current security arming status. Specific values ​​include: disarming mode, with a value of 0, indicating that all defense zones are disarmed; out-of-home arming mode, with a value of 1, indicating that all defense zones are monitored; home arming mode, with a value of 2, indicating that some defense zones are monitored; and sleeping arming mode, with a value of 3, indicating that defense zones outside the bedroom are monitored. The zone status array is used to store detailed status information for each zone. Each zone status includes: zone identifier, used to uniquely identify the zone; zone arming status, indicating whether the zone is under monitoring; sensor type, used to identify the type of sensor connected to the zone, including door and window sensors, infrared sensors, and smoke sensors; sensor current status, used to indicate the current status detected by the sensor; and zone operating mode, used to identify the operating mode of the zone, including normally open mode and normally closed mode. Delayed arming information is used to support the arming delay function, including: delay time, which is the number of seconds for arming delay set by the user; remaining delay time, which is the number of seconds remaining before arming takes effect. The arming delay function allows users to have a buffer period after leaving the system, avoiding false alarms during the arming process. The operating device identifier is used to record the device identifier that last modified the security status. This field plays an important role in conflict detection and can identify the source device of the data change. The timestamp field records the last time the data was modified, accurate to the millisecond level. The timestamp is a key basis for conflict detection and resolution, used to determine the order of multiple concurrent changes. The extended fields are reserved for storing alarm records and device status information, and have good scalability.

4. The method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service according to claim 3, characterized in that, The specific logical steps of S3 are as follows: S301: Local Data Update: First, update the local security status data, including modifying the corresponding field values. The system will automatically update the timestamp field to the current time and update the operating device identifier to the unique identifier of this device. S302: Write to distributed database: Write the updated complete security status data to the distributed key-value database. Since the database is configured with automatic synchronization mode, the write operation will trigger the synchronization mechanism of the distributed data service. S303: Automatic Data Push: After the distributed data service detects a data change, it automatically pushes the changed data to all other extension devices in the same distributed network through the SYNC_MODE_PUSH push mode. The push process is completed by the underlying operating system, and the application layer does not need to care about the network transmission details. S304: Push confirmation mechanism: The distributed data service has a built-in push confirmation mechanism to ensure that data is successfully delivered to the target device. If the push fails, it will automatically retry to ensure reliable data transmission. S305: Local State Persistence: Updated data is simultaneously persisted to local storage, ensuring that the latest security state can be restored after the device restarts.

5. The method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service according to claim 4, characterized in that, The specific logical steps of S4 are as follows: S401: Listener Registration: When the application starts, register a data change listener with the distributed database. Set the listener type to DATA_CHANGED to indicate that it listens for all data change events. S402: Change Event Reception: When a data change notification is received, the system calls back the listener and passes the change notification object. The change notification object contains the type of change and the specific data content of the change. The types of changes include addition, update and deletion. S403: Data Parsing: Extract security status data from the change notification, parse the JSON format data content, and restore the data content to a security status data structure object; S404: Conflict Detection: Compare the timestamps of the received data with those of the local data to determine if there is a conflict. If the timestamps are the same but the source devices are different, it indicates that there is a concurrent modification conflict. S405: Conflict resolution: If a conflict is detected, the conflict resolution mechanism is invoked for processing. The "last write wins" strategy is adopted, with the data with the larger timestamp taking precedence. If the timestamps are the same, the data from the main machine and the extension machine takes precedence. S406: Local Status Update: Updates the synchronized security status data to the local machine, and triggers a UI refresh to update and display the current arming status and the status of each defense zone. S407: Voice prompts: Play corresponding voice prompts according to the type of status change, including: play "arming successful" prompt when arming is successful, play "disarming successful" prompt when disarming is successful, and play "arming delayed" prompt at regular intervals when arming is delayed. S408: Local Persistence: Persist synchronized data to local storage to ensure that the device can be restored to the correct state after a restart.

6. The method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service according to claim 5, characterized in that, The specific logical steps of S5 are as follows: S501: Conflict detection conditions: When two devices modify the same data almost simultaneously and the difference in the timestamps of the modifications is within a preset threshold, a conflict is determined. S502: Timestamp comparison strategy: The "last write wins" strategy is adopted. The timestamps of two changes are compared and the change with the larger timestamp is taken as the final result to ensure the eventual consistency of the data. S503: Device Priority Strategy: When two changes have the same timestamp or a very small difference, the device priority strategy is used to resolve the conflict. The primary extension has a higher priority, and its changes take precedence over the changes of the secondary extension. S504: Built-in mechanism of distributed data service: OpenHarmony distributed data service itself also has a built-in conflict resolution mechanism, which can guarantee the eventual consistency of data at the system level and further enhance the reliability of the system. S505: Conflict Resolution Notification: After the conflict is resolved, the system will send a final result notification to all relevant devices to ensure that all devices eventually reach a consistent state.

7. The method for synchronizing the security status of multiple extension units based on OpenHarmony distributed data service according to claim 6, characterized in that, In S501, the threshold is configured by the system default or set by the user.

Images