Data processing method and device in platform migration scenario, equipment and medium

Abstract

The application provides a data processing method and device in a platform migration scenario, equipment and medium, relates to the technical field of Internet of Things, and the method comprises the following steps: a target platform queries a user mapping table and a device identity mapping relationship which are constructed in advance by responding to an access request initiated by a user, realizes user cross-platform identity recognition, and automatically executes login credential conversion and session reconstruction; after the session reconstruction is completed, the Internet of Things devices associated with a source platform are accessed to the target platform according to the device identity mapping relationship. Through the double mapping mechanism and the automatic migration process, the user does not need to manually register, re-login or re-networking, and only through a single regular access request, the full-link migration of identity authentication, login state migration and device access can be completed, which significantly reduces the user operation burden and improves the migration automation degree and user experience.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a data processing method, a data processing apparatus, an electronic device, and a readable storage medium for platform migration scenarios. Background Technology

[0002] In smart home device platform migration scenarios, users typically need to migrate deployed smart devices from an old device management platform to a new one. This migration process often involves transferring user identity information, switching device control permissions, and synchronizing device operating status. Users expect a smooth platform migration without interrupting normal device operation, maintaining continuity of device control and data integrity. However, during the migration process, users are required to re-register accounts, set passwords, and verify identity on the new platform, resulting in a fragmented migration experience and increasing the user's operational burden. Summary of the Invention

[0003] This invention provides a data processing method, apparatus, device, and medium for platform migration scenarios, to solve or partially solve the problem that users need to perform manual registration, re-login, and device rebinding operations during platform migration, which increases the user's operational burden.

[0004] This invention discloses a data processing method for platform migration scenarios, including: In response to an access request for the target platform, obtain the source platform identity identifier; Obtain a pre-built user mapping table between the target platform and the source platform, and query the target platform identity identifier of the target platform based on the user mapping table and the identity identifier of the source platform, and obtain the device identity mapping relationship between the source platform and the target platform; Based on the target platform identity identifier, perform login credential conversion and session reconstruction on the target platform; In response to the completion of session reconstruction, the IoT devices associated with the source platform are connected to the target platform according to the device identity mapping relationship.

[0005] In some feasible implementations, the method further includes: Obtain user registration timestamps, device binding feature information, and device identity identifiers of IoT devices associated with the source platform from the source platform; Based on the source platform identity identifier, the user registration timestamp, and the device binding feature information, a cross-platform platform mapping identifier is generated between the target platform and the source platform; The correspondence between the source platform identity identifier, the platform mapping identifier, and the target platform identity identifier is stored as the user mapping table.

[0006] In some feasible implementations, generating a cross-platform platform mapping identifier between the target platform and the source platform based on the source platform identity identifier, the user registration timestamp, and the device binding feature information includes: Obtain the platform instance identifier information of the source platform; The source platform identity identifier, the user registration timestamp, the device binding feature information, and the platform instance identifier information are combined, and the combination result is hashed to obtain the cross-platform platform mapping identifier between the target platform and the source platform.

[0007] Among some feasible implementation methods are: Obtain the binding relationship between the source platform identity identifier and the device identity identifier; Based on the binding relationship, a device identity mapping relationship is established between the source platform and the target platform.

[0008] In some feasible implementations, querying the target platform identity identifier of the target platform based on the user mapping table and the source platform identity identifier includes: If a target platform identity identifier associated with the source platform identity identifier exists in the user mapping table, then the target platform identity identifier is extracted from the user mapping table.

[0009] In some feasible implementations, the method further includes: If there is no target platform identity associated with the source platform identity in the user mapping table, a new target platform identity is generated on the target platform, and a mapping relationship is established between the source platform identity and the new target platform identity, and the mapping relationship is stored in the user mapping table.

[0010] In some feasible implementations, the step of performing login credential conversion and session reconstruction on the target platform based on the target platform identity includes: Obtain the login credentials of the source platform corresponding to the access request; Extract the permission feature information from the source platform login credentials; Obtain the security key system of the target platform, and reissue it according to the security key system using the target platform identity identifier and the permission feature information to obtain the target platform login credential adapted to the target platform; The target platform login credentials are used to establish a session on the target platform and restore the association between the source platform identity identifier and the device identity mapping relationship.

[0011] In some feasible implementations, connecting the IoT device associated with the source platform to the target platform according to the device identity mapping relationship includes: Obtain the device identifier of the IoT device associated with the source platform from the device identity mapping relationship; Send the device identifier to the cloud, receive the virtual device identifier corresponding to the device identifier generated by the cloud, and write the virtual device identifier into the device identity mapping relationship; A protocol adaptation unit is established, which is used to convert the control commands of the target platform in the standard protocol format into the source protocol format supported by the IoT device; The control commands received by the target platform for the IoT device are converted by the protocol adaptation unit and then sent to the IoT device. The system receives status data returned by the IoT device, converts it through the protocol adaptation unit, and then transmits it back to the target platform.

[0012] In some feasible implementations, the source platform and the target platform run in parallel during the migration process, and the method further includes: Obtain the user migration progress status identifier and the device migration progress status identifier of the IoT device; The processing path for the access request is determined based on the combination between the user migration progress status identifier and the device migration progress status identifier.

[0013] In some feasible implementations, determining the processing path of the access request based on the combination of the user migration progress status identifier and the device migration progress status identifier includes: If the user migration progress status is marked as not migrated and the device migration progress status is marked as not mapped, then the access request will be routed to the source platform for processing. If the user migration progress status is marked as "Migration in progress" and the device migration progress status is marked as "Mapped", then the write request in the access request will be written to both the source platform and the target platform simultaneously using a parallel write mechanism. If the user migration progress status is marked as migrated and the device migration progress status is marked as access completed, then the access request will be routed to the target platform for processing.

[0014] In some feasible implementations, after prioritizing routing the access request to the target platform for processing, the method further includes: If the target platform returns missing data or service abnormalities, the read request in the access request will be rolled back to the source platform for processing.

[0015] Among some feasible implementation methods are: Subscribe to the database operation logs or message queue events of the source platform; In response to capturing a data change event from the source platform, a global identifier is extracted from the data change event, and the event processing record table maintained by the target platform is read. If the global identifier is not recorded in the event handling record table, the target platform will perform data synchronization and write the global identifier into the event handling record table. If the global identifier has already been recorded in the event handling log table, then the data change event is discarded.

[0016] Among some feasible implementation methods are: Determine the control behavior of the target platform over the IoT device; Generate a corresponding control status record and a corresponding control status version identifier for the control behavior; The control status version identifier includes a global version number and a timestamp. The global version number is generated by the cloud corresponding to the target platform, and the timestamp is used to identify the actual time when the control behavior occurs.

[0017] Among some feasible implementation methods are: If the global version number of the current control status record is greater than the global version number of the latest control status record stored locally, then the current control status record will overwrite the latest control status record stored locally. If the global version number of the current control state record is equal to the global version number of the latest control state record stored locally, then the timestamps of the two are compared, and the control state record with the newer timestamp is the valid control state record. If the global version number and timestamp are the same, the valid control status record is determined according to the predetermined control source priority, wherein the predetermined control source priority is: the priority of the local control terminal is higher than the priority of the target platform, and the priority of the target platform is higher than the priority of the source platform.

[0018] Among some feasible implementation methods are: In response to the IoT device reconnecting from an offline state, the system receives the target device status record reported by the IoT device and the target device status version identifier corresponding to the device status record; If the target device status version identifier is less than the current status version identifier stored in the cloud, then the current device status record sent by the cloud is sent to the IoT device, overwriting the target device status record of the IoT device. If the target device status version identifier is greater than the current status version identifier stored in the cloud, then the current device status record stored in the target platform is updated according to the target device status record.

[0019] Among some feasible implementation methods are: Query the queue of instructions awaiting compensation; If there are unsuccessfully issued target control commands in the queue of commands to be compensated, the execution path of the target control commands will be recalculated using the current device status record of the IoT device. The target control command is sent to the IoT device according to the recalculated execution path.

[0020] In some feasible implementations, obtaining the source platform identity identifier in response to an access request for the target platform includes: In response to an access request for a target platform, the source platform identity identifier of the source platform is extracted from the access request, or the platform mapping identifier carried in the access request is queried from the user mapping table according to the platform mapping identifier, and the source platform identity identifier is obtained from the user mapping table.

[0021] This invention also discloses a data processing apparatus for platform migration scenarios, comprising: The access response module is used to respond to access requests for the target platform and obtain the source platform's identity identifier. The mapping query module is used to obtain a pre-built user mapping table between the target platform and the source platform, and query the target platform identity identifier of the target platform according to the user mapping table and the identity identifier of the source platform, and obtain the device identity mapping relationship between the source platform and the target platform; The session reconstruction module is used to perform login credential conversion and session reconstruction on the target platform based on the target platform identity identifier; The device access module is used to connect the IoT device associated with the source platform to the target platform according to the device identity mapping relationship in response to the completion of session reconstruction.

[0022] In some feasible implementations, the apparatus further includes: The information acquisition module is used to acquire user registration timestamps, device binding feature information, and device identity identifiers of IoT devices associated with the source platform from the source platform. The mapping identifier generation module is used to generate a cross-platform platform mapping identifier between the target platform and the source platform based on the source platform identity identifier, the user registration timestamp, and the device binding feature information; The mapping table storage module is used to store the correspondence between the source platform identity identifier, the platform mapping identifier and the target platform identity identifier as the user mapping table.

[0023] In some feasible implementations, the mapping identifier generation module is specifically used for: Obtain the platform instance identifier information of the source platform; The source platform identity identifier, the user registration timestamp, the device binding feature information, and the platform instance identifier information are combined, and the combination result is hashed to obtain the cross-platform platform mapping identifier between the target platform and the source platform.

[0024] Among some feasible implementation methods are: The binding relationship acquisition module is used to acquire the binding relationship between the source platform identity identifier and the device identity identifier; The device mapping establishment module is used to establish a device identity mapping relationship between the source platform and the target platform based on the binding relationship.

[0025] In some feasible implementations, the mapping query module is specifically used for: If a target platform identity identifier associated with the source platform identity identifier exists in the user mapping table, then the target platform identity identifier is extracted from the user mapping table. If there is no target platform identity associated with the source platform identity in the user mapping table, a new target platform identity is generated on the target platform, and a mapping relationship is established between the source platform identity and the new target platform identity, and the mapping relationship is stored in the user mapping table.

[0026] In some feasible implementations, the session reconstruction module is specifically used for: Obtain the login credentials of the source platform corresponding to the access request; Extract the permission feature information from the source platform login credentials; Obtain the security key system of the target platform, and reissue it according to the security key system using the target platform identity identifier and the permission feature information to obtain the target platform login credential adapted to the target platform; The target platform login credentials are used to establish a session on the target platform and restore the association between the source platform identity identifier and the device identity mapping relationship.

[0027] In some feasible implementations, the device access module is specifically used for: Obtain the device identifier of the IoT device associated with the source platform from the device identity mapping relationship; Send the device identifier to the cloud, receive the virtual device identifier corresponding to the device identifier generated by the cloud, and write the virtual device identifier into the device identity mapping relationship; A protocol adaptation unit is established, which is used to convert the control commands of the target platform in the standard protocol format into the source protocol format supported by the IoT device; The control commands received by the target platform for the IoT device are converted by the protocol adaptation unit and then sent to the IoT device. The system receives status data returned by the IoT device, converts it through the protocol adaptation unit, and then transmits it back to the target platform.

[0028] In some feasible implementations, the source platform and the target platform operate in parallel during the migration process, and the apparatus further includes: The progress identifier acquisition module is used to acquire the user migration progress status identifier and the device migration progress status identifier of the IoT device. The processing path determination module is used to determine the processing path of the access request based on the combination between the user migration progress status identifier and the device migration progress status identifier.

[0029] In some feasible implementations, the processing path determination module is specifically used for: If the user migration progress status is marked as not migrated and the device migration progress status is marked as not mapped, then the access request will be routed to the source platform for processing. If the user migration progress status is marked as "Migration in progress" and the device migration progress status is marked as "Mapped", then the write request in the access request will be written to both the source platform and the target platform simultaneously using a parallel write mechanism. If the user migration progress status is marked as migrated and the device migration progress status is marked as access completed, then the access request will be routed to the target platform for processing.

[0030] In some feasible implementations, after prioritizing routing the access request to the target platform for processing, the processing path determination module is further configured to: If the target platform returns missing data or service abnormalities, the read request in the access request will be rolled back to the source platform for processing.

[0031] Among some feasible implementation methods are: The event subscription module is used to subscribe to the database operation logs or message queue events of the source platform; The event handling module is used to respond to the capture of a data change event from the source platform, extract a global identifier from the data change event, and read the event handling record table maintained by the target platform; The synchronization execution module is used to perform data synchronization by the target platform and write the global identifier into the event processing record table if the global identifier is not recorded in the event processing record table. An event discarding module is used to discard the data change event if the global identifier has already been recorded in the event handling record table.

[0032] Among some feasible implementation methods are: A control behavior determination module is used to determine the control behavior of the target platform on the IoT device; The version identifier generation module is used to generate a corresponding control status record and a corresponding control status version identifier for the control behavior. The control status version identifier includes a global version number and a timestamp. The global version number is generated by the cloud corresponding to the target platform, and the timestamp is used to identify the actual time when the control behavior occurs.

[0033] Among some feasible implementation methods are: The version comparison module is used to overwrite the latest control status record stored locally with the current control status record if the global version number of the current control status record is greater than the global version number of the latest control status record stored locally. The version comparison module is also used to compare the timestamps of the two if the global version number of the current control state record is equal to the global version number of the latest control state record stored locally, and to take the control state record with the newer timestamp as the valid control state record. The version comparison module is also used to determine the valid control status record according to the predetermined control source priority if the global version number and timestamp are the same. The predetermined control source priority is: the priority of the local control terminal is higher than the priority of the target platform, and the priority of the target platform is higher than the priority of the source platform.

[0034] Among some feasible implementation methods are: The offline recovery module is used to receive the target device status record reported by the IoT device and the target device status version identifier corresponding to the device status record after the IoT device resumes connection from the offline state. The version comparison module is used to send the current device status record sent by the cloud to the IoT device if the target device status version identifier is less than the current status version identifier stored in the cloud, thereby overwriting the target device status record of the IoT device. The version comparison module is further configured to update the current device status record stored on the target platform according to the target device status record if the target device status version identifier is greater than the current status version identifier stored in the cloud.

[0035] Among some feasible implementation methods are: The instruction compensation module is used to query the queue of instructions to be compensated. The path recalculation module is used to recalculate the execution path of the target control command if there is a target control command that was not successfully issued in the queue of commands to be compensated; The instruction issuing module is used to issue the target control instruction to the IoT device according to the recalculated execution path.

[0036] In some feasible implementations, the access response module is specifically used for: In response to an access request for a target platform, the source platform identity identifier of the source platform is extracted from the access request, or the platform mapping identifier carried in the access request is queried from the user mapping table according to the platform mapping identifier, and the source platform identity identifier is obtained from the user mapping table.

[0037] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

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

[0039] The embodiments of the present invention have the following advantages: In this embodiment of the invention, the target platform obtains the source platform's identity identifier in response to a user's access request. Based on this source platform's identity identifier, it queries a pre-built user mapping table to determine the corresponding target platform's identity identifier. Simultaneously, it obtains the device identity mapping relationship between the source and target platforms. Through this dual mapping mechanism of the user mapping table and the device identity mapping relationship, not only is a seamless mapping of the user's identity from the source platform to the target platform achieved, allowing the user to access the target platform and operate existing devices without manual re-registration or re-login, but also login credential conversion and session reconstruction are automatically performed based on the queried target platform identity identifier, enabling the user to seamlessly migrate their login state without being aware of it. Furthermore, after session reconstruction, IoT devices associated with the source platform are connected to the target platform based on the device identity mapping relationship. This allows the devices to be managed by the target platform without any firmware upgrades or reconfiguration. Thus, with only a single interaction involving a regular access request, the entire migration process—from identity authentication and login state migration to device access—is automatically completed. This significantly reduces the user's operational burden in platform migration scenarios and improves the automation level and user experience of the migration process. Attached Figure Description

[0040] Figure 1 This is a flowchart of the steps of a data processing method in a platform migration scenario provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the data processing flow for a platform migration scenario provided in this embodiment of the invention; Figure 3 This is the control instruction stream for the platform migration scenario provided in this embodiment of the invention; Figure 4 This is a schematic diagram of the device reporting process in a platform migration scenario provided in this embodiment of the invention; Figure 5 This is a schematic diagram of the data synchronization process in a platform migration scenario provided in this embodiment of the invention; Figure 6 This is a structural block diagram of a data processing device for a platform migration scenario provided in an embodiment of the present invention. Detailed Implementation

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

[0042] As examples, the technical solutions provided in these embodiments can be applied to IoT cloud platform migration scenarios. In such scenarios, the source platform (old platform) has been deployed and running for many years, carrying a large number of existing user accounts and their bound massive IoT devices. Now, it is necessary to migrate the user system and device access relationships to the target platform (new platform). However, in the above scenario, existing technologies usually require existing users to manually re-register their accounts on the new platform and perform unbinding, reconfiguration, and rebinding operations on each old device. However, a large number of old devices are in a long-term unattended operation state after deployment, and users do not have or find it inconvenient to perform reconfiguration operations on the devices. This results in the migration process heavily relying on manual user participation, high migration costs, and poor user experience. At the same time, there is a lack of a continuous data synchronization mechanism between the source platform and the target platform during the migration. The status data reported by the devices and the control commands issued by the users cannot be kept consistent between the two platforms, which can easily lead to problems such as data loss, inconsistent device status, or control conflicts, and cannot guarantee the continuity of device control services during and after the migration.

[0043] In response, this invention employs a dual mapping mechanism based on the user mapping table and the device identity mapping relationship. When the target platform receives an access request initiated by a user, it can automatically complete the cross-platform identification of the user's identity and the login state migration by querying the pre-built user mapping table. Furthermore, it connects the IoT devices associated with the source platform to the target platform according to the device identity mapping relationship. This enables the user to automatically complete the entire migration process of identity authentication, login state migration, and device access with only one regular access request, significantly reducing the user's operational burden.

[0044] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, some technical features involved in the embodiments of the present invention are explained and described below: The platform, which can be an IoT cloud platform, includes server clusters, database systems, message middleware, and application programming interface (API) gateways deployed in the cloud. It is used to achieve unified management of IoT devices, maintenance of the user account system, storage and distribution of device status data, and issuance and routing of control commands. The source platform refers to the old platform to which the IoT devices are connected before migration, where the user account system is already in operation; the target platform refers to the new platform to which the IoT devices need to connect after migration, where the user account system needs to be rebuilt. In this embodiment of the invention, the source platform and the target platform are two logically independent platform instances that can run in parallel during the migration.

[0045] Internet of Things (IoT) devices can be intelligent terminal devices with network communication capabilities, including but not limited to smart air conditioners, smart refrigerators, smart lighting equipment, smart door locks, smart curtains, air purifiers, and robot vacuum cleaners. IoT devices interact with the platform via communication protocols (such as MQTT, HTTP, CoAP, or proprietary protocols). The relationship between the device and the platform is as follows: the device sends status data (such as temperature readings, on / off status, operating mode, etc.) to the platform, and the platform issues control commands to the device (such as turning on / off, temperature adjustment, mode switching, etc.). In this embodiment of the invention, IoT devices do not require firmware upgrades or communication protocol modifications; cross-platform migration can be completed through platform-side compatibility adaptation.

[0046] A platform identity identifier can be a string or numeric code used by the platform to uniquely identify a user account. In this embodiment of the invention, the platform identity identifier includes a source platform identity identifier and a target platform identity identifier. The source platform identity identifier is the unique identifier of the user account in the source platform (i.e., the old platform user UID), for example, "User_Old_12345"; the target platform identity identifier is the unique identifier of the user account in the target platform (i.e., the new platform user UID), for example, "User_New_67890". A correspondence is established between the source platform identity identifier and the target platform identity identifier through a user mapping table.

[0047] A device identity identifier can be a string, numeric code, or MAC address used by a platform to uniquely identify an IoT device. In this embodiment of the invention, the device identity identifier includes a source platform device identifier and a target platform virtual device identifier. The source platform device identifier is the original device ID of the IoT device in the source platform (e.g., "AC_Kitchen_01"), and the target platform virtual device identifier is the logical device ID generated by virtualization technology for the same IoT device in the target platform (e.g., "vDev_0001"). A correspondence is established between the source platform device identifier and the target platform virtual device identifier through a device identity mapping relationship, thereby enabling the target platform to achieve compatible access and control of the source platform device.

[0048] Reference Figure 1 The diagram illustrates a flowchart of a data processing method for a platform migration scenario provided in an embodiment of the present invention, which may specifically include the following steps: Step 101: In response to the access request for the target platform, obtain the source platform identity identifier; In this embodiment of the invention, the target platform can continuously monitor access requests from application clients (e.g., new applications on a user's mobile phone or a new application on a smart screen). When a user initiates an access request to the target platform through an application client, the target platform, upon receiving the access request, can extract the source platform identity identifier corresponding to the source platform from the access request. For example, if a user opens a new app, clicks the login button in an app, or the app automatically initiates a heartbeat request in the background, the target platform can determine the source platform identity identifier based on the access request.

[0049] In some feasible implementations, for the process of determining the source platform identity, the target platform may respond to an access request for the target platform by extracting the source platform identity from the access request, or by querying the user mapping table according to the platform mapping identifier carried in the access request, and obtaining the source platform identity from the user mapping table.

[0050] In practice, the access request can carry the login credentials of the source platform (such as a token issued by the old platform). The target platform parses the login credentials and reads the user identity identifier (i.e., the old platform UID) from the specified field of the credentials, which is then used as the identity identifier of the source platform.

[0051] Correspondingly, in another implementation, the access request can carry a pre-cached platform mapping identifier. The target platform can then query the user mapping table based on this identifier to obtain the corresponding source platform identity identifier. This process can be triggered when the user first accesses the target platform through a new application. In subsequent accesses, the application can cache the source platform identity identifier locally and include it with each request.

[0052] The platform mapping identifier can be a logical identifier used to uniquely identify a user account's identity during cross-platform migration from the source platform to the target platform; that is, a unique identity anchor point for the user's identity during the cross-platform migration process. Correspondingly, the user mapping table can be a collection of mapping relationship data stored in the target platform, which can be used to record the correspondence between the user's identity identifier, the platform mapping identifier, and the target platform's identity identifier on the source platform.

[0053] Optionally, the user mapping table may include at least: a source platform identity identifier (e.g., storing the old platform user UID) for use as a query index; a platform mapping identifier (e.g., storing the platform mapping identifier) ​​for uniquely identifying the user's identity anchor point during cross-platform migration; and a target platform identity identifier (e.g., storing the new platform user UID) for identifying the target platform account identity corresponding to the user after migration.

[0054] In addition, the user mapping table is pre-built during the migration initialization phase and continuously maintained and updated during the migration. When the target platform receives a user access request, it can quickly locate and extract the corresponding target platform user identity using the source platform user identity identifier or platform mapping identifier as the query key value, thereby realizing automatic identification and cross-platform mapping of user identity and avoiding users manually re-registering accounts or logging in repeatedly.

[0055] In some feasible implementations, during the migration initialization phase, the target platform can first generate a platform mapping identifier, construct a user mapping table, and establish device identity mapping relationships. This is achieved by obtaining user registration timestamps, device binding feature information, and device identity identifiers of IoT devices associated with the source platform from the source platform. Then, based on the source platform identity identifier, user registration timestamps, and device binding feature information, a cross-platform platform mapping identifier is generated between the target platform and the source platform. Finally, the correspondence between the source platform identity identifier, the platform mapping identifier, and the target platform identity identifier is stored as a user mapping table.

[0056] Furthermore, the binding relationship between the source platform identity identifier and the device identity identifier can be obtained, and then a device identity mapping relationship between the source platform and the target platform can be established based on the binding relationship.

[0057] In the specific implementation, the target platform can first obtain the following information from the source platform: source platform identity identifier (i.e., the account ID of each user in the source platform), user registration timestamp for each user (i.e., the timestamp recorded by the system when the user registers an account on the source platform), device binding feature information (i.e., the device identity identifier of each device bound by the user and its binding time, binding type, and other features), as well as the binding relationship information between the source platform identity identifier and the device identity identifier.

[0058] Subsequently, the target platform can generate a platform mapping identifier based on the source platform's identity identifier, user registration timestamp, and device binding characteristics. This mapping identifier serves as a unique identity anchor for the user's identity during the cross-platform migration process. It uniquely identifies a user's cross-platform identity during migration, ensuring that the same user's identity can be accurately associated and identified across different platforms, avoiding identity confusion caused by changes in usernames, phone numbers, or other information.

[0059] Optionally, in some feasible implementations, the target platform obtains the platform instance identifier information (e.g., "GreePlatform") of the source platform, then concatenates the source platform identity identifier, user registration timestamp, device binding feature information, and platform instance identifier information in a predetermined order to obtain a combined string. A hash operation (e.g., SHA-256) is then performed on this combined string, and the hash result is used as the platform mapping identifier. The platform mapping identifier is unique and unforgeable. Even if two users have the same old platform UID (which may occur under different source platform instances), the final generated mapping identifiers will be different because the platform instance identifier information and device binding feature information participate in the hash operation, thus ensuring the global uniqueness of the cross-platform mapping identifier.

[0060] Based on the generated platform mapping identifier, the target platform can also store the correspondence between the source platform identity identifier, the platform mapping identifier, and the target platform identity identifier as a user mapping table for subsequent process queries. Simultaneously, the target platform can also establish a correspondence between the source platform device identity identifier and the target platform virtual device identifier based on the binding relationship between the source platform identity identifier and the device identity identifier, storing this as a device identity mapping relationship for use when IoT devices connect. The processes of generating the platform mapping identifier, constructing the user mapping table, and establishing the device identity mapping relationship can be completed during the migration initialization phase, without the user's awareness.

[0061] For example, during the migration initialization phase, the target platform can obtain Mr. Zhang's user ID "User_Old_12345", registration timestamp "2020-01-01 10:00:00", device binding characteristic information (air conditioner device ID "AC_001", binding time "2020-01-15", etc.), and old platform instance identifier "GreePlatform_V2" from the old platform. Then, the target platform can concatenate this information into the string "User_Old_12345|2020-01-01 10:00:00|AC_001|GreePlatform_V2", perform a SHA-256 hash operation, and obtain the mapping identifier "a3f5c7e9...". Then, a user mapping table record is created: Old UID "User_Old_12345" - Mapping Identifier "a3f5c7e9..." - New UID "User_New_67890".

[0062] Step 102: Obtain the pre-built user mapping table between the target platform and the source platform, and query the target platform identity identifier of the target platform according to the user mapping table and the identity identifier of the source platform, and obtain the device identity mapping relationship between the source platform and the target platform; In this embodiment of the invention, after obtaining the source platform's identity identifier, the target platform can read a pre-built user mapping table from its local storage (e.g., a database or cache system), and then perform a query operation in the user mapping table using the source platform's identity identifier as the index key to determine the target platform's identity identifier corresponding to that source platform's identity identifier. Simultaneously, the target platform also obtains a pre-built device identity mapping relationship between the source platform and the target platform from its local storage for use in subsequent device access processes.

[0063] In some feasible implementations, the user mapping table query process involves the target platform using the source platform's identity identifier as an index. If a target platform identity identifier associated with the source platform's identity identifier exists in the user mapping table, it is extracted from the table. If no such identifier exists, a new target platform identity identifier is generated on the target platform, and a mapping relationship is established between the source and new identifiers. This mapping relationship is then stored in the user mapping table. This query and branching process ensures that a valid target platform identity identifier is obtained regardless of whether a mapping record exists in the user mapping table, preventing user access failures due to incomplete mapping table coverage.

[0064] In addition, the device identity mapping relationship can be a set of mapping relationship data stored on the target platform side, which can be used to record the correspondence between the source platform device identity identifier and the target platform virtual device identifier, including at least the source platform device identifier field and the target platform virtual device identifier field.

[0065] For example, using Mr. Zhang's scenario, the target platform queries the user mapping table using "User_Old_12345" as the index and finds a corresponding record already existing in the table: "User_Old_12345" maps to the target platform user ID "User_New_67890". The target platform extracts "User_New_67890" as its identity identifier. Simultaneously, the target platform reads the device identity mapping relationship and obtains the mapping records for Mr. Zhang's 10 devices, including the virtual device ID "vDev_0001" corresponding to the old ID of the air conditioner device "AC_Kitchen_01".

[0066] Optionally, during the migration process, the source platform and the target platform can operate in parallel. The target platform can also perform the following request routing processing: the target platform obtains the user migration progress status identifier and the IoT device migration progress status identifier, and determines the processing path of the current access request based on the combination of the user migration progress status identifier and the device migration progress status identifier. The user migration progress status identifier includes at least three states: not migrated, migrating, and migrated; the device migration progress status identifier includes at least three states: not mapped, mapped, and access completed. This invention does not impose any limitations on these states.

[0067] In the specific implementation, if the user migration progress status is marked as "Not Migrated" and the device migration progress status is marked as "Not Mapped," it means that the user and their device have not yet started migrating. The target platform will route the access request to the source platform for processing, and the source platform will continue to provide services. If the user migration progress status is marked as "Migrable" and the device migration progress status is marked as "Mapped," it means that the user is in the process of migrating. The target platform adopts a parallel write mechanism for write requests (such as device control commands, configuration modifications, etc.) in the access request, that is, writes to both the source platform and the target platform simultaneously to ensure data consistency between the two platforms during the migration. If the user migration progress status is marked as "Migrated" and the device migration progress status is marked as "Access Completed," it means that the user has completed the full migration, and the target platform will prioritize routing the access request to the target platform for processing. Furthermore, after prioritizing routing the access request to the target platform for processing, if the target platform returns missing data or service anomalies (for example, the current status data of a device in the target platform has not been synchronized), the target platform will fall back the read request in the access request to the source platform to obtain the data, ensuring that business continuity is not affected.

[0068] Furthermore, after prioritizing the routing of access requests to the target platform for processing, if the target platform returns data missing or a service exception (e.g., the current status data of a device on the target platform has not yet been synchronized from the source platform, or the device status query interface of the target platform times out), the target platform will roll back the read request in the access request to the source platform for processing. Specifically, when the target platform detects an exception while processing a read request that is prioritized to its own platform (e.g., returning a 404 status code indicating that the data does not exist, or returning a 5xx status code (e.g., 500, 501, 502, 503, 504, 505, etc.) indicating that the service is unavailable, or the request times out), the target platform automatically reroutes the read request to the source platform, which then reads the corresponding data and returns it to the application. The aforementioned rollback mechanism ensures that during the migration transition, even if the target platform's data is not fully synchronized or the service experiences temporary anomalies, users' read requests (such as viewing device status, querying device lists, etc.) can still receive normal responses. This effectively guarantees the continuity and availability of business access during and after the migration, avoiding user experience issues caused by incomplete data or service fluctuations on the target platform.

[0069] For example, Mr. Zhang's air purifier has completed user mapping and device virtualization identifier generation, but its current PM2.5 concentration data has not yet been synchronized from the source platform to the target platform. When Mr. Zhang checks the air purifier's PM2.5 concentration in the new app, the target platform receives the read request and prioritizes local processing. Finding that the device's status data is missing from its local database (data missing in return), the target platform automatically rolls back the read request to the source platform. After obtaining the PM2.5 concentration value "35μg / m³" from the source platform, it returns it to Mr. Zhang's new app. The entire rollback process is completed in milliseconds; Mr. Zhang is unaware of the change in data source and can still view the device status normally.

[0070] Step 103: Based on the target platform identity identifier, perform login credential conversion and session reconstruction on the target platform; In this embodiment of the invention, after obtaining the target platform identity identifier, the target platform can use the target platform identity identifier to perform login credential conversion, converting the user's source platform login credentials into target platform login credentials that can be identified and verified by the target platform, and establishing a session locally on the target platform based on the converted login credentials to complete the login state migration.

[0071] In practical implementation, login credentials can be digital credentials used by the platform to verify a user's identity and authorize their access to resources, establishing a trusted session context between the user and the platform. Login credentials can take various forms, such as token strings based on JSON Web Token (JWT) format, server-generated session identifiers (Session IDs), or cryptographically signed cookies.

[0072] The login credentials must include at least the following information: user identity identifier (e.g., user ID), used to uniquely identify the holder of the credentials; permission feature information (e.g., user role, operation permission bitmap, credentials validity period, etc.), used to limit the scope of operations that the holder of the credentials can perform on the platform; and anti-tampering information (e.g., digital signature or message authentication code), used to prevent the credentials from being forged or tampered with.

[0073] In some feasible implementations, the target platform can extract the corresponding source platform login credentials from the access request, extract the permission feature information from the source platform login credentials, then obtain the target platform's security key system, and reissue the credentials using the target platform's identity identifier and permission feature information according to the security key system to obtain target platform login credentials adapted to the target platform. Finally, the target platform login credentials are used to establish a session on the target platform and restore the association between the source platform's identity identifier and the device identity mapping relationship.

[0074] The source platform login credential refers to the login credential issued by the source platform after the user completes authentication. It is stored locally on the application and can be used directly without the user having to re-enter their account and password during the migration process. The target platform login credential refers to the login credential re-issued by the target platform through a login credential conversion process. It is used for subsequent identity authentication and access authorization of the user on the target platform. The target platform can re-issue the target platform login credential based on the target platform's identity identifier and the permission feature information extracted from the source platform login credential, according to the target platform's security key system. This allows for a seamless migration of the login state from the source platform to the target platform without requiring the user to re-enter their account and password.

[0075] Furthermore, the security key system can be a set of encryption mechanisms and key materials used by the target platform to issue and verify login credentials. This security key system should include at least the following: a signature algorithm, such as HMAC-SHA256 (symmetric encryption), RSA-SHA256 (asymmetric encryption), or ECDSA (elliptic curve cryptography), used to digitally sign the payload of the login credential, ensuring that the credential is not tampered with during transmission and storage; key materials, such as symmetric keys or public-private key pairs, used to perform signature generation and signature verification operations; and credential format specifications, such as the JWT (JSON Web Token) standard format or a platform-defined token format, used to define the names, data types, and encoding methods of each field in the login credential.

[0076] In this embodiment of the invention, the security key system of the target platform is independent of that of the source platform, and the signature algorithms and key materials used by the two may differ. During the login credential conversion process, the target platform obtains its own security key system configuration and reissues the target platform login credential according to its signature algorithm and key materials, thereby ensuring that the converted credential can be correctly recognized and verified by the target platform. For example, the source platform uses the HMAC-SHA256 symmetric encryption algorithm with the key "OldSecretKey"; the target platform uses the RSA-SHA256 asymmetric encryption algorithm with the private key "NewPrivateKey". When converting the credential, the target platform does not use the source platform's algorithm and key, but instead uses its own RSA private key to sign the new credential.

[0077] Accordingly, the permission feature information can be a data set of user permission scope and access control attributes recorded in the login credential, used to limit the types of operations that the credential holder can perform and the range of resources that can be accessed on the platform. The permission feature information includes at least the following: user role information, such as administrator (admin), ordinary user (user), guest (guest), etc., used to identify the user's permission level on the platform; operation permission bitmap or permission list, such as "device control permission," "device management permission," "user management permission," "data viewing permission," etc., used to precisely control the user's access to specific functions; and credential validity information, such as the credential issuance time and expiration time, used to limit the valid usage period of the credential. In this embodiment of the invention, the permission feature information is embedded in the source platform login credential. During the login credential conversion process, the target platform parses and extracts this permission feature information from the source platform login credential and uses it as one of the payload contents, re-issuing the target platform login credential according to the target platform's credential format specification, so that the user's permission scope after migration remains consistent with that before migration. For example, the permission feature information extracted after parsing the login credentials of the source platform is: role "admin", operation permissions "{\"device_control\":true,\"device_config\":true,\"user_manage\":false}, and validity period "2026-12-31T23:59:59Z". When the target platform reissues a new credential, it writes the above permission feature information into the permission field of the new credential as is, ensuring that the user has the same operation permissions on the target platform as on the source platform.

[0078] During the credential conversion and session establishment process, the target platform obtains the login credentials from the source platform corresponding to the access request (e.g., a JWT token or session cookie issued by the old platform), and extracts the permission feature information (e.g., user role, device operation permission bitmap, token validity period, etc.) from the source platform login credentials. Next, it obtains the target platform's security key system (e.g., the signature algorithm and corresponding key materials used by the target platform to issue tokens), and reissues the credentials using the target platform's identity identifier and permission feature information according to this security key system, obtaining a target platform login credential adapted to the target platform. A session is established on the target platform using the target platform login credential, and the association between the source platform identity identifier and the device identity mapping is restored, allowing the user to directly control the original device without rebinding it in subsequent operations. Through the above login credential conversion and session reconstruction process, the user can obtain a valid login state on the target platform without manually logging in again.

[0079] For example, Mr. Zhang's access request carried the old platform token "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiVXNlcl9PbGRfMTIzNDUiLCJyb2xlIjoiYWRtaW4ifQ.xxxxxx". The target platform parses the token to extract the user ID "User_Old_12345" and permission information (admin role). Then, based on the target platform's own key system (e.g., RS256 signature algorithm), it reissues a new token, "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoiVXNlcl9OZXdfNjc4OTAiLCJyb2xlIjoiYWRtaW4ifQ.yyyyyy," using the same admin permissions. The target platform uses this new token to establish a local session. After Mr. Zhang's app obtains the new token, all subsequent requests can be recognized by the target platform by carrying this new token, without requiring further login.

[0080] Step 104: In response to the completion of session reconstruction, the IoT devices associated with the source platform are connected to the target platform according to the device identity mapping relationship.

[0081] Based on the process described in the foregoing embodiments, after the session reconstruction is completed, the device access process can be triggered. The target platform reads the device identity mapping relationship and, for each IoT device associated with the user in the source platform, performs access processing on the target platform side, ensuring that the device is in an active state on the target platform—able to be discovered by the application, receive control commands, and report status data. Once access is complete, control commands initiated by the user for the device through the target platform will be routed to the corresponding physical device on the source platform for execution according to the device identity mapping relationship. The status data returned by the physical device is also transmitted back to the target platform according to the mapping relationship.

[0082] In some feasible implementations, the device access process may include: the target platform obtaining the source device identifier (e.g., device ID "AC_001" in the old platform) of the IoT device associated with the source platform from the device identity mapping relationship; sending the source device identifier to the cloud; the cloud querying the device's model information and capability description information based on the source device identifier, and generating a corresponding virtual device identifier for the device based on this information; the target platform receiving the virtual device identifier generated by the cloud and writing it into the device identity mapping relationship; the target platform establishing a protocol adaptation unit, which is used to convert control commands in the target platform's standard protocol format into the source protocol format supported by the IoT device; when the target platform receives control commands for the IoT device, it converts the control commands from the target platform's standard protocol format to the source protocol format through the protocol adaptation unit and sends them to the IoT device; when it receives status data returned by the IoT device, it converts the status data from the source protocol format to the target platform's standard protocol format through the protocol adaptation unit and sends it back to the target platform. Through the above protocol adaptation mechanism, physical devices can be managed and controlled by the target platform without modifying firmware, upgrading communication protocols, or reconfiguring the network.

[0083] Status data can be a collection of information generated by IoT devices during operation, reflecting the current working status and operating parameters of the devices. Specifically, status data includes at least the following: device operating status information (e.g., device on / off status, standby / running / fault status, etc.), device measurement values ​​(e.g., temperature sensor readings, humidity values, PM2.5 concentration, power consumption, etc.), device configuration parameters (e.g., currently set temperature value, operating mode, fan speed setting, etc.), and device anomaly information (e.g., fault codes, error logs, etc.). Status data is usually actively sent to the platform by the device according to a predetermined reporting cycle (e.g., once every 30 seconds) or when the status changes (e.g., immediately after the user adjusts the temperature via remote control). Its format varies depending on the device manufacturer and communication protocol, such as JSON format (e.g., {"temperature":26,"humidity":60,"status":"running"}), binary format (e.g., 0xA10x010x1A), or custom text format, etc.

[0084] In this embodiment of the invention, after the status data is reported by the IoT device to the source platform, data changes are captured and synchronized to the target platform through a migration service. Simultaneously, when the target platform receives the status data returned by the IoT device, the protocol adaptation unit converts the status data from the source protocol format to the target platform's standard protocol format. This ensures that status data from devices of different manufacturers and protocol types can be parsed, stored, and displayed in a unified format on the target platform. Status data is the fundamental data unit for achieving closed-loop device monitoring and control, and ensuring status consistency.

[0085] For example, the target platform obtains the source device identifier "AC_Kitchen_01" of Mr. Zhang's air conditioner based on the device identity mapping relationship, sends it to the cloud device virtualization service, and the cloud generates the corresponding virtual device identifier "vDev_0001" and returns it. The target platform writes this mapping relationship into the mapping table. Subsequently, the target platform establishes a protocol adaptation unit and configures bidirectional conversion rules between the target platform's standard protocol (e.g., HTTPS+JSON) and the air conditioner's private protocol (e.g., a binary protocol based on UDP). When Mr. Zhang clicks "Turn on the air conditioner" in the new APP, the target platform receives the start command in the standard protocol format. The protocol adaptation unit converts it into a binary command "0xA10x010x00" that the air conditioner can recognize and sends it to the physical air conditioner. After the air conditioner executes the command, it returns status data "0xA10x010x01". The protocol adaptation unit converts this data into the standard protocol format "{"status": "on"}" and sends it back to the target platform. The target platform updates the device status and presents it to Mr. Zhang. Throughout the entire process, Mr. Zhang does not need to perform any reconfiguration or rebinding operations on the air conditioner.

[0086] Furthermore, in this embodiment of the invention, the target platform can also execute an incremental data synchronization process. Optionally, the target platform can subscribe to the source platform's database operation logs (e.g., MySQL's Binlog) or message queue events (e.g., Kafka Topics) to monitor data changes in the source platform in real time. Then, in response to capturing a data change event from the source platform, it can extract a global identifier from the data change event and read the event processing record table maintained by the target platform. If the global identifier is not recorded in the event processing record table, the target platform performs data synchronization (writes the changed data to the target platform's local database) and writes the global identifier into the event processing record table, marking it as "processed". If the global identifier has already been recorded in the event processing record table, the data change event is discarded and not written again.

[0087] In the above process, the database operation log is a sequential record file automatically generated by the database system when performing data write, update, or delete operations, used to record detailed information about each data change in the database. The database operation log includes at least the following: the type of change operation (e.g., INSERT, UPDATE, DELETE), the name and fields of the data table involved in the change, the data values ​​before and after the change (e.g., the old value before the update and the new value after the update), the transaction ID that performed the operation, the operation timestamp, and the source information of the operation (e.g., connection ID or user ID). Common implementations of database operation logs include MySQL's Binlog, PostgreSQL's Write-Ahead Log, and Oracle's Redo Log. In this embodiment of the invention, the target platform subscribes to the source platform's database operation log (e.g., subscribing to MySQL Binlog through the Canal component) to capture data change events in the source platform in real time, thereby achieving incremental synchronization of all database-level changes such as device status data, user information, and binding relationships. Since the database operation log records the complete history of data changes, subscribing to the log can ensure that no changes are missed during data synchronization between the source platform and the target platform, and does not intrude on the business logic of the source platform.

[0088] Message queue events are structured event notifications proactively published to a message queue by business services running on the source platform when specific business operations occur, enabling asynchronous communication and decoupling between systems. A message queue event includes at least the following: event type (e.g., "DeviceStatusChanged", "UserInfoUpdated", "DeviceBonded"), event producer identifier, event occurrence time, and event payload (i.e., specific business data, such as device ID, latest status value, user ID, etc.). Common implementations of message queues include Apache Kafka, RabbitMQ, RocketMQ, and AWS SQS. Unlike database operation logs, message queue events are proactive notifications at the business level, with content closer to business semantics (e.g., "device online event" rather than an abstract "UPDATE statement"), and the message format is defined by the business system.

[0089] In this embodiment of the invention, the target platform subscribes to message queue events from the source platform (e.g., subscribing to the "DeviceStatus" Topic in Kafka) to receive real-time events such as device status changes and user information changes proactively published by the source platform's business system, and processes these as data change events synchronously. The advantages of the message queue event approach are clear business semantics, high real-time performance, and suitability for scenarios where the source platform's business system already has message publishing capabilities.

[0090] For data change events, a unified abstract data structure can be carried in database operation logs or message queue events, describing a single data change in the source platform. It is a standardized encapsulation of data changes (database operation logs and message queue events) from different sources in the source platform, provided for the target platform to perform data synchronization operations. A data change event encapsulates at least the following fields: a global identifier (a unique string generated based on device identity, operation type, and timestamp according to predetermined rules, used for idempotent control), a change type (e.g., "status update," "device binding," "user information modification," etc.), a device identity identifier (the IoT device ID involved in the change), a user identity identifier (the user ID involved in the change), change content (the specific changed data, such as the latest device temperature value, user mobile phone number, etc.), and a timestamp (the actual time the change occurred). Data change events provide a unified abstraction of data changes from two different sources: database operation logs and message queue events. This allows the target platform to synchronize data using a unified format and processing logic, regardless of whether the change event originates from a log or a message. In this embodiment of the invention, after capturing database operation logs or message queue events, the migration service of the target platform extracts and encapsulates the key information in the events into standardized data change events, and then performs idempotency verification based on the global identifier of the event. After confirming that there are no errors, it performs data synchronization.

[0091] Furthermore, the event handling log table can be a log table stored on the target platform, used to record global identifiers of data change events that have been successfully processed by the target platform, in order to achieve idempotent control during data synchronization. The event handling log table includes at least the following fields: a global identifier field (stores a unique identifier for the processed data change event), a processing timestamp field (records the time when the event was processed), and a processing status field (marks whether the event was processed successfully).

[0092] In this embodiment of the invention, when the target platform receives a data change event, it first queries the event processing record table using the global identifier of the event as an index. If the global identifier is not recorded in the event processing record table, a data synchronization operation is performed, and the global identifier is written to the event processing record table and marked as "processed." If the global identifier has been recorded, it indicates that the change event is a duplicate delivery (e.g., due to network retransmission, duplicate message queue consumption, etc.), and the target platform directly discards the event and no longer performs data writing. Through the above mechanism, the event processing record table and the global identifier in the data change event together constitute an idempotent control scheme for data synchronization, ensuring that the same data change will not be executed repeatedly in scenarios such as network jitter, duplicate message delivery, or system abnormal retries, thereby guaranteeing the eventual consistency of data between the source platform and the target platform.

[0093] Furthermore, a global identifier can be generated by combining the device identity, operation type, and timestamp corresponding to the data change event according to a predetermined rule (e.g., the MD5 value of "Device_AC001|STATUS_CHANGE|1700000000"), used to uniquely distinguish each data change event. Through this idempotent control mechanism, eventual data consistency between the source and target platforms is guaranteed, while avoiding data duplication issues caused by network jitter or duplicate message delivery.

[0094] Furthermore, in this embodiment of the invention, the target platform can also execute a multi-terminal concurrent state convergence process. Optionally, the target platform determines each control action it takes on IoT devices (including control commands issued by the user through the APP, control triggered by device timed policies, control triggered by scene linkage, etc.), and generates a corresponding control state record and a corresponding control state version identifier for each control action. The control state version identifier can include a global version number and a timestamp. The global version number can be uniformly and incrementally generated by the target platform's cloud platform and can be used to identify the global order of the state update among all control actions. The timestamp is used to identify the actual time the control action occurred.

[0095] The control status record can be an abstract data structure used to uniformly describe the control intent and operational results of IoT devices at a certain moment. It includes at least user-issued control commands (e.g., turning on the air conditioner, setting the temperature to 24℃, switching to cooling mode, etc.), status information fed back by the device after executing the control commands (e.g., execution success / failure, current temperature has reached the set value, etc.), and target status information determined or merged by the cloud (e.g., the final device state determined after conflict resolution). The control status record is generated by the target platform each time a control action occurs. It is a complete and unified abstraction of the device control process and results, providing a unified comparison object for state convergence in scenarios with concurrent operations from multiple control terminals. The control status record is independent of specific transmission protocols and platform implementations, enabling control actions from different control terminals (e.g., new apps, old apps, local physical buttons, timing strategies, etc.) to be compared and conflict determined in a unified format.

[0096] Accordingly, the control state version identifier can be a unique sequential label used to identify the control state record on the global timeline, generated by the target platform when generating the control state record. The control state version identifier includes at least the following two dimensions: global version number and timestamp. The global version number is uniformly incremented by the target platform's cloud (e.g., incremented by 1 each time a new state record is generated), used to identify the global order of the state record among all control actions, independent of the local clocks of each control terminal, thus avoiding order confusion caused by asynchronous clocks of different devices; the timestamp is used to identify the time when the control action occurred in the actual physical world, recorded by the control initiator (e.g., APP, local remote control, etc.) when initiating control. During state convergence, the order of the global version number and timestamp may not be completely consistent due to network latency, local clock deviation, etc., at different control terminals. The target platform comprehensively judges the two according to predetermined conflict resolution rules: first, compare the global version number, with the larger version number being the latest state; if the version numbers are the same, compare the timestamps, with the newer timestamp being the valid state; if both are the same, the valid state is determined according to the control source priority. Through the aforementioned two-dimensional control state version identification mechanism, it is ensured that in complex scenarios with concurrent operations from multiple control terminals, the order of control actions can be accurately determined, and the device state can converge consistently.

[0097] In practical implementation, when multiple devices concurrently operate on the same IoT device, the target platform can use the following conflict resolution rules for state convergence: If the global version number of the current control state record is greater than the global version number of the latest locally stored control state record, then the current control state record overwrites the latest locally stored control state record; if the global version number of the current control state record is equal to the global version number of the latest locally stored control state record, then the timestamps of the two are compared, and the control state record with the newer timestamp is the valid control state record; if both the global version number and the timestamp are the same, then the valid control state record is determined according to the predetermined control source priority. The predetermined control source priority is as follows: the priority of the local control terminal (e.g., the device's local physical buttons or remote control) is higher than the priority of the target platform, and the priority of the target platform is higher than the priority of the source platform. Through the above comprehensive judgment mechanism based on version number, timestamp, and source priority, the device state can be consistently converged in scenarios with concurrent operation of multiple control terminals.

[0098] Furthermore, in this embodiment of the invention, the target platform can also execute the following offline device recovery process: In response to the IoT device reconnecting from an offline state (e.g., network outage, power failure restart, signal interruption, etc.), the target platform receives the target device status record reported by the IoT device and the target device status version identifier corresponding to the device status record; if the target device status version identifier is less than the current status version identifier stored in the cloud, it indicates that the device missed several status updates during the offline period, and the device-side status lags behind the cloud, then the target platform sends the current device status record sent by the cloud to the IoT device, overwriting the target device status record of the IoT device, so that the device status is consistent with the cloud; if the target device status version identifier is greater than the current status version identifier stored in the cloud, it indicates that the device performed some operations on its own during the offline period (e.g., the user adjusted the device parameters through a local remote control), and the device-side status is ahead of the cloud, then the target platform updates its locally stored current device status record according to the target device status record, so that the cloud status is consistent with the actual device status.

[0099] The device status record can be a complete set of information reflecting the current actual operating status of the IoT device, stored locally in the device's local memory and continuously maintained and updated by the device itself during operation. The device status record includes at least the following: the device's current operating status information (e.g., on / off, standby / running / fault), the device's measured values ​​(e.g., current temperature reading, humidity value, PM2.5 concentration, power consumption), the device's configuration parameters (e.g., currently set target temperature, operating mode, fan speed level), and the device's most recently executed control command and execution result (e.g., the content of the most recently received command and the success / failure indicator).

[0100] Compared to the state records stored in the cloud, device state records reflect the actual state of the physical entity of the device, rather than the expected or presumed state recorded in the cloud. When the device is running normally online, the cloud state and the device state are synchronized through a real-time reporting mechanism. However, when the device is offline, users may directly operate the device through local control terminals (such as physical remote controls, device buttons, infrared remote controls, etc.), causing changes in the device's state that the cloud cannot detect. In this case, a difference arises between the device's state and the cloud state. In the offline recovery process of this embodiment, after the device reconnects, it reports its locally stored device state records to the target platform. The target platform compares these records with the current state records stored in the cloud to determine which state is closer to the actual state and performs bidirectional state calibration accordingly.

[0101] Furthermore, the status version identifier can be an identifier maintained on the device side to identify the version of the device status record, updated by the device itself with each status change. The status version identifier can be represented as a monotonically increasing version number (e.g., the device's local version number increments by 1 with each status change) or a timestamp (e.g., the device's local time at the time of the status change), used to indicate the freshness of the device-side status record. The status version identifier is maintained locally by the device and is independent of the global version number generated by the cloud: the cloud-generated global version number is used to identify the update order of the cloud-side status, while the device-side status version identifier is used to identify the update order of the device-side status. While the device is offline, the status version identifier increments synchronously each time the device's status changes due to local operations (e.g., from V5 to V6); however, the cloud will not update its stored current status version identifier during this period because it cannot receive reports from the device. Once the device reconnects, the target platform quickly determines which side is up-to-date by comparing the device-side status version identifier reported by the device with the current status version identifier stored in the cloud. This determines the calibration direction: if the device-side version identifier is less than the cloud-side version identifier, the device is lagging, and the cloud sends the latest status to the device to overwrite it; if the device-side version identifier is greater than the cloud-side version identifier, the cloud is lagging, and the cloud updates its local record with the device-reported status. Through this bidirectional comparison mechanism between the device-side and cloud-side status version identifiers, automatic status calibration is achieved after offline devices reconnect, without manual intervention.

[0102] After the aforementioned state calibration is completed, the target platform can also query the queue of commands to be compensated. If there are unsuccessfully issued target control commands in the queue (i.e., commands received by the target platform during device offline but not sent to the device for execution), the target platform uses the current device state record of the IoT device to recalculate the execution path of the target control command (e.g., determining whether the command is still valid in the current device state, whether parameters need to be adjusted, etc.), and issues the target control command to the IoT device according to the recalculated execution path. Through the above offline calibration and compensation mechanism, it is ensured that the device can automatically complete state calibration and compensate for unexecuted commands after recovering from abnormal situations such as network outages and power outages, without manual intervention.

[0103] The execution path calculation process can be described as the process by which the target platform, after the device recovers from offline operation, performs validity checks, parameter adjustments, and rearranges the unsuccessfully issued control commands in the compensation command queue. Optionally, the specific implementation of the execution path calculation can be as follows: When the target platform queries the queue of commands to be compensated, each control command in the queue must contain at least the following information: target device identifier, command type (e.g., "switch control", "temperature setting", "mode switching", etc.), command parameters (e.g., target temperature value 26℃, target mode "cooling", etc.), and the original timestamp of the command issuance. When calculating the execution path, the target platform first obtains the device status record currently reported by the IoT device (including the device's current operating status, measurement values, configuration parameters, and version identifier), and then calculates the execution path according to the following logic: Step 1: Validity Determination. The target platform determines whether the compensation command is still valid in the current device state based on the device's current status record. Specifically: If the target parameter of the instruction is consistent with the corresponding parameter in the current status record of the device (for example, the instruction to be compensated is "set temperature 24℃", while the temperature in the current status record of the device is already 24℃), then it is determined that the instruction does not need to be executed, and it is removed from the queue of instructions to be compensated and will not be issued again. If the instruction is a time-sensitive instruction (such as "delayed shutdown", "scheduled power-on", etc.), and the difference between its original issuance timestamp and the current time exceeds the instruction's validity window (for example, the validity window of a scheduled instruction is 24 hours after the original issuance time; if it exceeds this window, it is determined to have expired), then the instruction is determined to be invalid, removed from the queue of instructions to be compensated, and will no longer be issued. If the target device controlled by the instruction is currently in a state that does not support the instruction (for example, the device is currently in a powered-off state, and the instruction to be compensated is "adjust the wind speed", but the device does not support wind speed adjustment when powered off), then the instruction is determined to be invalid in the current state, and the target platform will process it according to a predetermined strategy (for example, turn on the device first and then execute the instruction, or mark the instruction as "suspend execution" and retry it after the device state changes).

[0104] Step 2, Conflict Detection and Merging. If multiple control commands targeting the same device exist in the queue of commands to be compensated, the target platform merges these commands. Specifically, if multiple commands have the same operation type but different parameters (e.g., "Set temperature 26℃" received first, followed by "Set temperature 24℃"), only the last valid command is retained (based on the later timestamp of the command issuance), and the remaining commands are removed from the queue. If multiple commands have different operation types (e.g., one is an "on" command, and the other is a "Set temperature 24℃"), the execution path is arranged according to the order of "execute the preceding command first, then execute the following command" (e.g., execute the "on" command first, and then execute the "Set temperature 24℃" command after the device reports that it is on).

[0105] Step 3: Execution Path Orchestration. Based on the validity assessment and conflict detection results, the target platform rearranges the instructions to be compensated according to time sequence and dependencies, forming an ordered execution path. The execution path includes at least the following information: the execution order of the instructions, the target device identifier for each instruction, the instruction type and parameters, and the dependencies between instructions (e.g., the "on" instruction must be executed before the "temperature setting" instruction). After orchestration, the target platform sends control instructions to the device one by one in the order of the execution path, and after each instruction is executed, it decides whether to continue executing the next instruction based on the device's feedback status (if an instruction fails, the target platform can record the reason for the failure and skip that instruction, continuing to execute subsequent instructions, or retry according to a predetermined retry strategy).

[0106] Through the above-described execution path calculation process, the control commands in the compensation command queue may become invalid or outdated during device offline due to user operations via local control or timed policies. The target platform ensures, through validity judgment, conflict detection, and path orchestration, that only commands that are still valid and necessary in the current state will be compensated and issued. This avoids problems such as abnormal device status or inconsistencies between user expectations and actual behavior caused by issuing outdated or conflicting commands. For example, during device offline, a user sets the air conditioner temperature to 24℃ using a local remote control. The cloud stores a compensation command for "setting temperature 26℃" issued by the user via the APP before offline. When the device reconnects, the target platform, through execution path calculation (validity judgment step), finds that the current device temperature record is 24℃, while the target parameter of the compensation command is 26℃. However, 26℃ is inconsistent with the 24℃ recorded in the current device status record. If 26℃ is directly issued, it will overwrite the user's local setting during offline, which does not meet the user's actual expectations. The target platform further compares the command issuance timestamp with the device status change timestamp: the original issuance timestamp of the command to be compensated is 14:00, and the device local temperature change timestamp is 14:30 (operated by the user via the local remote control). It is determined that the device-side change occurred later. Therefore, the current device status is used as the standard, and the command to be compensated is removed from the queue and no longer issued, thereby avoiding the error of overwriting the user's local operations during offline periods.

[0107] For example, Mr. Zhang's air conditioner went offline for four hours overnight due to a network failure. During this time, Mr. Zhang tried to adjust the air conditioner temperature from 26℃ to 24℃ using a new app, but the command failed due to the device being offline and was stored in the compensation command queue. When the network was restored in the early morning, the air conditioner proactively reported its current status to the target platform: temperature 26℃, version number V5. The target platform compared the stored version number and found it to be V5, consistent with the original, indicating no calibration was needed. Subsequently, it checked the compensation command queue and found an unexecuted "set to 24℃" command. Based on the air conditioner's current status (running, 26℃), the target platform determined that the command was still valid, recalculated the execution path, and sent it to the air conditioner, successfully adjusting it to 24℃. When Mr. Zhang woke up in the morning, he found the air conditioner at 24℃, the entire process requiring no manual operation.

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

[0109] In this embodiment of the invention, the target platform obtains the source platform's identity identifier in response to a user's access request. Based on this source platform's identity identifier, it queries a pre-built user mapping table to determine the corresponding target platform's identity identifier. Simultaneously, it obtains the device identity mapping relationship between the source and target platforms. Through this dual mapping mechanism of the user mapping table and the device identity mapping relationship, not only is a seamless mapping of the user's identity from the source platform to the target platform achieved, allowing the user to access the target platform and operate existing devices without manual re-registration or re-login, but also login credential conversion and session reconstruction are automatically performed based on the queried target platform identity identifier, enabling the user to seamlessly migrate their login state without being aware of it. Furthermore, after session reconstruction, IoT devices associated with the source platform are connected to the target platform based on the device identity mapping relationship. This allows the devices to be managed by the target platform without any firmware upgrades or reconfiguration. Thus, with only a single interaction involving a regular access request, the entire migration process—from identity authentication and login state migration to device access—is automatically completed. This significantly reduces the user's operational burden in platform migration scenarios and improves the automation level and user experience of the migration process.

[0110] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the following examples are provided for illustrative purposes: As some examples, see Figure 2 The diagram illustrates the data processing flow for a platform migration scenario provided in this embodiment of the invention. Specifically: Step S101, Data Extraction (User + Device). During the migration initialization phase, the target platform extracts in batches existing user account information and associated IoT device information from the source platform, including user identity identifiers, user registration timestamps, device identity identifiers, and binding relationship information between users and devices.

[0111] Step S102: Establish mapping relationships (UID / Device ID). Based on the extracted user and device information, the target platform generates a cross-platform unified identity mapping identifier, and accordingly establishes a user mapping table (recording the correspondence between the user identity identifiers of the source platform and the user identity identifiers of the target platform) and a device identity mapping relationship (recording the correspondence between the device identifiers of the source platform and the virtual device identifiers of the target platform). The user mapping table is used for identity query and automatic identification when users access the target platform in the future, and the device identity mapping relationship is used to associate physical devices with virtual device entities of the target platform when devices are accessed in the future.

[0112] Step S103, simulated registration (creating a new account). The target platform automatically creates a new account (i.e., target platform identity) for each source platform user based on the user mapping table, without requiring manual operation from the user.

[0113] Step S104: Initiate parallel operation of both platforms. During the migration, the source platform and the target platform operate in parallel. The target platform takes over the routing and scheduling of user requests, dynamically scheduling requests to the source platform or the target platform for processing based on the user migration progress and the device migration progress.

[0114] Step S105: Incremental synchronization + dual write. During the migration process, the target platform subscribes to the source platform's database operation logs or message queue events to capture data changes on the source platform in real time and synchronize them to the target platform. At the same time, a parallel write mechanism is used for write requests to ensure data consistency between the two platforms.

[0115] Step S106: The user switches to the new APP. The user initiates an access request through the target platform's application. The target platform automatically identifies the user's identity based on the user mapping table, completes the login credential conversion and session reconstruction, and connects the IoT devices associated with the source platform to the target platform according to the device identity mapping relationship, realizing a seamless migration for the user.

[0116] Step S107, End. The user has completed the migration, and all subsequent requests will be handled by the target platform.

[0117] It should be noted that in the above process, steps S101 to S105 are all background preprocessing processes, executed automatically during the migration initialization phase, and are completely imperceptible to the user; step S106 is the only interactive action that is perceptible to the user, that is, the user only needs to switch to the new APP and initiate a regular access request, and all subsequent migration operations are automatically completed by the target platform. The entire process embodies the core inventive concept that "the user only needs to make one regular access request to automatically complete the entire migration chain of identity authentication, login state migration and device access".

[0118] Accordingly, refer to Figure 3 The control command flow for a platform migration scenario provided in an embodiment of the present invention is shown, specifically: Step S201: The APP initiates a control command. The user performs operations on the IoT device via the application (APP) (e.g., turning on the air conditioner, adjusting the temperature, checking the device status, etc.), and the application sends the corresponding control command request to the target platform (new platform). During the migration, all requests from the application are uniformly sent to the target platform, which then performs unified routing and scheduling.

[0119] Step S202: The new platform performs route determination. After receiving the control command request, the target platform obtains the current user migration progress status identifier and the corresponding device migration progress status identifier, and determines the processing path for the current request based on the combination of the two statuses. The user migration progress status identifier includes at least three states: not migrated, migrating in progress, and migrated; the device migration progress status identifier includes at least three states: not mapped, mapped, and access completed.

[0120] Step S203: Determine whether the target platform or source platform will handle the request. Based on the routing determination result, the target platform will route the control command request to the corresponding processing path: If the user status is "Migrated" and the device status is "Connection Completed", it means that the user and their device have completed the full migration. The target platform will prioritize routing control command requests to this platform (the new platform) for processing, and the new platform will directly execute operations such as issuing control commands and updating status.

[0121] If the user status is "not migrated" and the device status is "not mapped", it means that the user and their device have not yet started the migration. The target platform will route the control command request to the source platform (old platform) for processing, and the old platform will continue to provide complete device control services.

[0122] If the user status is "Migration in Progress" and the device status is "Mapped", it means that the user is in the process of migration. The target platform adopts a dual-write synchronous mechanism for write requests (such as device on / off control, parameter settings, etc.), that is, the control command is sent to both the source platform and the target platform at the same time, and the device status is updated on both the source platform and the target platform at the same time to ensure data consistency between the two platforms during the migration. For read requests (such as querying device status, getting device list, etc.), they are first routed to either the source platform or the target platform for processing.

[0123] Through the routing judgment mechanism based on user migration progress and device migration progress, dynamic scheduling of control command flow during migration is realized, ensuring that user control requests can be effectively processed and business access is not interrupted, regardless of the migration status of users and devices.

[0124] Accordingly, refer to Figure 4 This diagram illustrates the device reporting process for a platform migration scenario provided in this embodiment of the invention. Specifically: Step S301: Device reports status data. Following its original operating logic, the IoT device periodically reports status data (such as temperature readings, switch status, operating mode, fault codes, etc.) to the source platform (old platform) according to its existing operating logic, or when its status changes. Since no firmware upgrades or configuration modifications were performed during the migration process, the device still only knows the access address of the source platform; therefore, all data reported by the device still first reaches the source platform. There is no awareness or modification on the device side during this process.

[0125] In step S302, the old platform receives and records device data. After receiving the status data reported by the device, the source platform processes and stores the data according to the original logic (e.g., updating the device status table in the database, recording device operation logs, etc.). After the source platform completes the data writing, a data change record will be generated in its database operation log (e.g., MySQL's Binlog) or message queue. This record contains information such as the changed device identity, change type, change content, and timestamp.

[0126] Step S303: The migration service listens for and captures data changes. The migration service module in the target platform subscribes to the database operation logs (e.g., subscribing to MySQL Binlog via the Canal component) or message queue events (e.g., subscribing to Kafka Topics) of the source platform to monitor data change events in the source platform in real time. When a new data change record is generated on the source platform, the migration service immediately captures the change event and extracts a global identifier (generated based on the device identity, operation type, and timestamp according to a predetermined rule, used to uniquely identify each data change event and prevent the same change from being synchronized multiple times due to network retransmission or duplicate message delivery) and the change content (e.g., the latest status value of the device) from the event.

[0127] In step S304, the migration service synchronizes the changes to the new platform. After capturing a data change event, the migration service queries the event processing record table maintained by the target platform based on the global identifier in the event and performs idempotency verification. If the global identifier is not recorded in the event processing record table, the migration service writes the changed data to the database of the target platform (new platform), updates the status record of the corresponding virtual device in the new platform, and simultaneously writes the global identifier to the event processing record table, marking it as "processed". If the global identifier has already been recorded, the change event is discarded and not written again. Through the above process, the status data reported by the device is automatically synchronized from the source platform to the target platform with low latency (seconds to milliseconds) without requiring any changes to the device.

[0128] The migration service is a logical module in the target platform that is responsible for executing the aforementioned incremental data synchronization process. It can be deployed independently as a microservice or run as a built-in functional module of the target platform.

[0129] It should be noted that the device reporting stream, together with the aforementioned control command stream, constitutes a complete closed loop of data flow during the migration: the control commands issued by the user through the application flow through the path "APP → New Platform (Route Judgment) → Dual Write Synchronization → New Platform / Old Platform → Device" (downlink), while the status data reported by the device flows through the path "Device → Old Platform → Migration Service → New Platform" (uplink). The downlink direction ensures that the commands issued by the user from either end (new APP or old APP) take effect simultaneously on both platforms through the dual write synchronization mechanism, while the uplink direction ensures that the status data reported by the device is synchronized from the source platform to the target platform in real time through the incremental synchronization mechanism. The two work together to achieve the overall technical effect of seamless switching between the old and new platforms, consistent and uninterrupted data, and uninterrupted business access during the migration, thereby ensuring that users can obtain a consistent device control experience and accurate device status information regardless of whether they use the new APP or the old APP.

[0130] In addition, refer to Figure 5 The diagram illustrates the data synchronization process for a platform migration scenario provided in this embodiment of the invention. Specifically: Step S401: Data changes occur on the old platform. The source platform (old platform) continuously generates data changes during operation, including updates to device-reported status data (e.g., temperature changes, on / off state switching), records of user-issued control commands, modifications to user information, and changes to device binding relationships. When the source platform performs data write operations (e.g., updating the device status table in the MySQL database, recording operation logs), it automatically generates corresponding data change logs (e.g., MySQL's Binlog) or publishes the change events to a message queue (e.g., Kafka, RocketMQ, etc.).

[0131] Step S402: MQ / log capture and transmission of change events. The migration service module in the target platform pre-subscribes to the database operation logs or message queue events of the source platform. When the source platform generates new data change logs or a new change event appears in the message queue, the migration service captures the change event in real time through the log subscription component or message queue consumer. The change event carries at least the following information: global identifier, change type, change content, device identifier, user identifier, and timestamp. Among them, the global identifier is generated based on the device identifier, operation type, and timestamp according to a predetermined rule, and is used to uniquely identify each data change event, preventing the same change from being synchronized multiple times due to network retransmission or duplicate message delivery.

[0132] Step S403: The new platform consumes the change event and synchronizes data. After capturing the change event, the migration service sends it to the data synchronization interface of the target platform (new platform). Upon receiving the change event, the target platform queries its locally maintained event processing record table based on the global identifier in the event and performs idempotency verification: if the global identifier is not recorded in the event processing record table, the target platform performs data synchronization, writes the changed data to its local database, and writes the global identifier to the event processing record table, marking it as "processed"; if the global identifier has already been recorded, the target platform directly discards the change event and does not write it again. Through the above idempotency control mechanism based on the global identifier, the eventual consistency of data between the source platform and the target platform is ensured, while avoiding data duplication caused by network retransmission, duplicate message delivery, or abnormal retries. This data synchronization stream continues to run during the migration until the migration is complete.

[0133] It should be noted that this data synchronization stream, together with the aforementioned control command stream and device reporting stream, constitutes a complete closed loop of data flow during the migration: In the downlink direction, the control commands issued by the user through the application flow through "APP → New Platform (routing judgment) → Dual write synchronization → New Platform / Old Platform → Device", ensuring that the control commands take effect simultaneously on both platforms; In the uplink direction, the status data reported by the device is synchronized to the target platform in real time through the path "Device → Old Platform → Migration Service → New Platform"; and this data synchronization stream further covers all data change types other than device reporting (such as user information modification, device binding relationship change, etc.), transmitting all data change events from the source platform to the target platform in real time through the channel "Old Platform → MQ / Log → New Platform", achieving final consistency of all data. The above three data streams work together to ensure that during the migration, regardless of whether the user uses the new APP or the old APP, they can obtain a consistent device control experience, accurate device status information, and a complete user data view.

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

[0135] Reference Figure 6 The diagram illustrates a structural block diagram of a data processing device for a platform migration scenario provided in an embodiment of the present invention, which may specifically include the following modules: Access response module 601 is used to respond to access requests for the target platform and obtain the source platform identity identifier. The mapping query module 602 is used to obtain a pre-built user mapping table between the target platform and the source platform, and query the target platform identity identifier of the target platform according to the user mapping table and the identity identifier of the source platform, and obtain the device identity mapping relationship between the source platform and the target platform; The session reconstruction module 603 is used to perform login credential conversion and session reconstruction on the target platform based on the target platform identity identifier; The device access module 604 is used to connect the IoT device associated with the source platform to the target platform according to the device identity mapping relationship in response to the completion of session reconstruction.

[0136] In some feasible implementations, the apparatus further includes: The information acquisition module is used to acquire user registration timestamps, device binding feature information, and device identity identifiers of IoT devices associated with the source platform from the source platform. The mapping identifier generation module is used to generate a cross-platform platform mapping identifier between the target platform and the source platform based on the source platform identity identifier, the user registration timestamp, and the device binding feature information; The mapping table storage module is used to store the correspondence between the source platform identity identifier, the platform mapping identifier and the target platform identity identifier as the user mapping table.

[0137] In some feasible implementations, the mapping identifier generation module is specifically used for: Obtain the platform instance identifier information of the source platform; The source platform identity identifier, the user registration timestamp, the device binding feature information, and the platform instance identifier information are combined, and the combination result is hashed to obtain the cross-platform platform mapping identifier between the target platform and the source platform.

[0138] Among some feasible implementation methods are: The binding relationship acquisition module is used to acquire the binding relationship between the source platform identity identifier and the device identity identifier; The device mapping establishment module is used to establish a device identity mapping relationship between the source platform and the target platform based on the binding relationship.

[0139] In some feasible implementations, the mapping query module 602 is specifically used for: If a target platform identity identifier associated with the source platform identity identifier exists in the user mapping table, then the target platform identity identifier is extracted from the user mapping table. If there is no target platform identity associated with the source platform identity in the user mapping table, a new target platform identity is generated on the target platform, and a mapping relationship is established between the source platform identity and the new target platform identity, and the mapping relationship is stored in the user mapping table.

[0140] In some feasible implementations, the session reconstruction module 603 is specifically used for: Obtain the login credentials of the source platform corresponding to the access request; Extract the permission feature information from the source platform login credentials; Obtain the security key system of the target platform, and reissue it according to the security key system using the target platform identity identifier and the permission feature information to obtain the target platform login credential adapted to the target platform; The target platform login credentials are used to establish a session on the target platform and restore the association between the source platform identity identifier and the device identity mapping relationship.

[0141] In some feasible implementations, the device access module 604 is specifically used for: Obtain the device identifier of the IoT device associated with the source platform from the device identity mapping relationship; Send the device identifier to the cloud, receive the virtual device identifier corresponding to the device identifier generated by the cloud, and write the virtual device identifier into the device identity mapping relationship; A protocol adaptation unit is established, which is used to convert the control commands of the target platform in the standard protocol format into the source protocol format supported by the IoT device; The control commands received by the target platform for the IoT device are converted by the protocol adaptation unit and then sent to the IoT device. The system receives status data returned by the IoT device, converts it through the protocol adaptation unit, and then transmits it back to the target platform.

[0142] In some feasible implementations, the source platform and the target platform operate in parallel during the migration process, and the apparatus further includes: The progress identifier acquisition module is used to acquire the user migration progress status identifier and the device migration progress status identifier of the IoT device. The processing path determination module is used to determine the processing path of the access request based on the combination between the user migration progress status identifier and the device migration progress status identifier.

[0143] In some feasible implementations, the processing path determination module is specifically used for: If the user migration progress status is marked as not migrated and the device migration progress status is marked as not mapped, then the access request will be routed to the source platform for processing. If the user migration progress status is marked as "Migration in progress" and the device migration progress status is marked as "Mapped", then the write request in the access request will be written to both the source platform and the target platform simultaneously using a parallel write mechanism. If the user migration progress status is marked as migrated and the device migration progress status is marked as access completed, then the access request will be routed to the target platform for processing.

[0144] In some feasible implementations, after prioritizing routing the access request to the target platform for processing, the processing path determination module is further configured to: If the target platform returns missing data or service abnormalities, the read request in the access request will be rolled back to the source platform for processing.

[0145] Among some feasible implementation methods are: The event subscription module is used to subscribe to the database operation logs or message queue events of the source platform; The event handling module is used to respond to the capture of a data change event from the source platform, extract a global identifier from the data change event, and read the event handling record table maintained by the target platform; The synchronization execution module is used to perform data synchronization by the target platform and write the global identifier into the event processing record table if the global identifier is not recorded in the event processing record table. An event discarding module is used to discard the data change event if the global identifier has already been recorded in the event handling record table.

[0146] Among some feasible implementation methods are: A control behavior determination module is used to determine the control behavior of the target platform on the IoT device; The version identifier generation module is used to generate a corresponding control status record and a corresponding control status version identifier for the control behavior. The control status version identifier includes a global version number and a timestamp. The global version number is generated by the cloud corresponding to the target platform, and the timestamp is used to identify the actual time when the control behavior occurs.

[0147] Among some feasible implementation methods are: The version comparison module is used to overwrite the latest control status record stored locally with the current control status record if the global version number of the current control status record is greater than the global version number of the latest control status record stored locally. The version comparison module is also used to compare the timestamps of the two if the global version number of the current control state record is equal to the global version number of the latest control state record stored locally, and to take the control state record with the newer timestamp as the valid control state record. The version comparison module is also used to determine the valid control status record according to the predetermined control source priority if the global version number and timestamp are the same. The predetermined control source priority is: the priority of the local control terminal is higher than the priority of the target platform, and the priority of the target platform is higher than the priority of the source platform.

[0148] Among some feasible implementation methods are: The offline recovery module is used to receive the target device status record reported by the IoT device and the target device status version identifier corresponding to the device status record after the IoT device resumes connection from the offline state. The version comparison module is used to send the current device status record sent by the cloud to the IoT device if the target device status version identifier is less than the current status version identifier stored in the cloud, thereby overwriting the target device status record of the IoT device. The version comparison module is further configured to update the current device status record stored on the target platform according to the target device status record if the target device status version identifier is greater than the current status version identifier stored in the cloud.

[0149] Among some feasible implementation methods are: The instruction compensation module is used to query the queue of instructions to be compensated. The path recalculation module is used to recalculate the execution path of the target control command if there is a target control command that was not successfully issued in the queue of commands to be compensated; The instruction issuing module is used to issue the target control instruction to the IoT device according to the recalculated execution path.

[0150] In some feasible implementations, the access response module 601 is specifically used for: In response to an access request for a target platform, the source platform identity identifier of the source platform is extracted from the access request, or the platform mapping identifier carried in the access request is queried from the user mapping table according to the platform mapping identifier, and the source platform identity identifier is obtained from the user mapping table.

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

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

[0153] This invention also provides a readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the data processing method embodiments described above in the platform migration scenario, achieving the same technical effects. To avoid repetition, these details will not be elaborated upon here. The readable storage medium may include, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

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

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

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

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

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

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

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

[0161] The above provides a detailed description of a data processing method and a data processing device for a platform migration scenario provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A data processing method for platform migration scenarios, characterized in that, include: In response to an access request for the target platform, obtain the source platform identity identifier; Obtain a pre-built user mapping table between the target platform and the source platform, and query the target platform identity identifier of the target platform based on the user mapping table and the identity identifier of the source platform, and obtain the device identity mapping relationship between the source platform and the target platform; Based on the target platform identity identifier, perform login credential conversion and session reconstruction on the target platform; In response to the completion of session reconstruction, the IoT device associated with the source platform is connected to the target platform according to the device identity mapping relationship; The method further includes: Obtain user registration timestamps, device binding feature information, and device identity identifiers of IoT devices associated with the source platform from the source platform; Based on the source platform identity identifier, the user registration timestamp, and the device binding feature information, a cross-platform platform mapping identifier is generated between the target platform and the source platform; The correspondence between the source platform identity identifier, the platform mapping identifier, and the target platform identity identifier is stored as the user mapping table; The step of connecting the IoT device associated with the source platform to the target platform according to the device identity mapping relationship includes: Obtain the device identifier of the IoT device associated with the source platform from the device identity mapping relationship; Send the device identifier to the cloud, receive the virtual device identifier corresponding to the device identifier generated by the cloud, and write the virtual device identifier into the device identity mapping relationship; A protocol adaptation unit is established, which is used to convert the control commands of the target platform in the standard protocol format into the source protocol format supported by the IoT device; The control commands received by the target platform for the IoT device are converted by the protocol adaptation unit and then sent to the IoT device. The system receives status data returned by the IoT device, converts it through the protocol adaptation unit, and then transmits it back to the target platform.

2. The method according to claim 1, characterized in that, The step of generating a cross-platform platform mapping identifier between the target platform and the source platform based on the source platform identity identifier, the user registration timestamp, and the device binding feature information includes: Obtain the platform instance identifier information of the source platform; The source platform identity identifier, the user registration timestamp, the device binding feature information, and the platform instance identifier information are combined, and the combination result is hashed to obtain the cross-platform platform mapping identifier between the target platform and the source platform.

3. The method according to claim 1, characterized in that, Also includes: Obtain the binding relationship between the source platform identity identifier and the device identity identifier; Based on the binding relationship, a device identity mapping relationship is established between the source platform and the target platform.

4. The method according to claim 1, characterized in that, The step of querying the target platform identity identifier of the target platform based on the user mapping table and the source platform identity identifier includes: If a target platform identity identifier associated with the source platform identity identifier exists in the user mapping table, then the target platform identity identifier is extracted from the user mapping table.

5. The method according to claim 1 or 4, characterized in that, Also includes: If there is no target platform identity associated with the source platform identity in the user mapping table, a new target platform identity is generated on the target platform, and a mapping relationship is established between the source platform identity and the new target platform identity, and the mapping relationship is stored in the user mapping table.

6. The method according to claim 1, characterized in that, The step of performing login credential conversion and session reconstruction on the target platform based on the target platform identity identifier includes: Obtain the login credentials of the source platform corresponding to the access request; Extract the permission feature information from the source platform login credentials; Obtain the security key system of the target platform, and reissue it according to the security key system using the target platform identity identifier and the permission feature information to obtain the target platform login credential adapted to the target platform; The target platform login credentials are used to establish a session on the target platform and restore the association between the source platform identity identifier and the device identity mapping relationship.

7. The method according to claim 1, characterized in that, During the migration process, the source platform and the target platform operate in parallel, and the method further includes: Obtain the user migration progress status identifier and the device migration progress status identifier of the IoT device; The processing path for the access request is determined based on the combination between the user migration progress status identifier and the device migration progress status identifier.

8. The method according to claim 7, characterized in that, Determining the processing path of the access request based on the combination of the user migration progress status identifier and the device migration progress status identifier includes: If the user migration progress status is marked as not migrated and the device migration progress status is marked as not mapped, then the access request will be routed to the source platform for processing. If the user migration progress status is marked as "Migration in progress" and the device migration progress status is marked as "Mapped", then the write request in the access request will be written to both the source platform and the target platform simultaneously using a parallel write mechanism. If the user migration progress status is marked as migrated and the device migration progress status is marked as access completed, then the access request will be routed to the target platform for processing.

9. The method according to claim 8, characterized in that, After prioritizing routing the access request to the target platform for processing, the method further includes: If the target platform returns missing data or service abnormalities, the read request in the access request will be rolled back to the source platform for processing.

10. The method according to claim 1, characterized in that, Also includes: Subscribe to the database operation logs or message queue events of the source platform; In response to capturing a data change event from the source platform, a global identifier is extracted from the data change event, and the event processing record table maintained by the target platform is read. If the global identifier is not recorded in the event handling record table, the target platform will perform data synchronization and write the global identifier into the event handling record table. If the global identifier has already been recorded in the event handling log table, then the data change event is discarded.

11. The method according to claim 1, characterized in that, Also includes: Determine the control behavior of the target platform over the IoT device; Generate a corresponding control status record and a corresponding control status version identifier for the control behavior; The control status version identifier includes a global version number and a timestamp. The global version number is generated by the cloud corresponding to the target platform, and the timestamp is used to identify the actual time when the control behavior occurs.

12. The method according to claim 11, characterized in that, Also includes: If the global version number of the current control status record is greater than the global version number of the latest control status record stored locally, then the current control status record will overwrite the latest control status record stored locally. If the global version number of the current control state record is equal to the global version number of the latest control state record stored locally, then the timestamps of the two are compared, and the control state record with the newer timestamp is the valid control state record. If the global version number and timestamp are the same, the valid control status record is determined according to the predetermined control source priority, wherein the predetermined control source priority is: the priority of the local control terminal is higher than the priority of the target platform, and the priority of the target platform is higher than the priority of the source platform.

13. The method according to claim 1, characterized in that, Also includes: In response to the IoT device reconnecting from an offline state, the system receives the target device status record reported by the IoT device and the target device status version identifier corresponding to the device status record; If the target device status version identifier is less than the current status version identifier stored in the cloud, then the current device status record sent by the cloud is sent to the IoT device, overwriting the target device status record of the IoT device. If the target device status version identifier is greater than the current status version identifier stored in the cloud, then the current device status record stored in the target platform is updated according to the target device status record.

14. The method according to claim 13, characterized in that, Also includes: Query the queue of instructions awaiting compensation; If there are unsuccessfully issued target control commands in the queue of commands to be compensated, the execution path of the target control commands will be recalculated using the current device status record of the IoT device. The target control command is sent to the IoT device according to the recalculated execution path.

15. The method according to claim 1, characterized in that, The step of obtaining the source platform identity identifier in response to an access request for the target platform includes: In response to an access request for a target platform, the source platform identity identifier of the source platform is extracted from the access request, or the platform mapping identifier carried in the access request is queried from the user mapping table according to the platform mapping identifier, and the source platform identity identifier is obtained from the user mapping table.

16. A data processing device for platform migration scenarios, characterized in that, include: The access response module is used to respond to access requests for the target platform and obtain the source platform's identity identifier. The mapping query module is used to obtain a pre-built user mapping table between the target platform and the source platform, and query the target platform identity identifier of the target platform according to the user mapping table and the identity identifier of the source platform, and obtain the device identity mapping relationship between the source platform and the target platform; The session reconstruction module is used to perform login credential conversion and session reconstruction on the target platform based on the target platform identity identifier; The device access module is used to connect the IoT device associated with the source platform to the target platform according to the device identity mapping relationship in response to the completion of session reconstruction. The device further includes: The information acquisition module is used to acquire user registration timestamps, device binding feature information, and device identity identifiers of IoT devices associated with the source platform from the source platform. The mapping identifier generation module is used to generate a cross-platform platform mapping identifier between the target platform and the source platform based on the source platform identity identifier, the user registration timestamp, and the device binding feature information; The mapping table storage module is used to store the correspondence between the source platform identity identifier, the platform mapping identifier and the target platform identity identifier as the user mapping table; Specifically, the device access module is used for: Obtain the device identifier of the IoT device associated with the source platform from the device identity mapping relationship; Send the device identifier to the cloud, receive the virtual device identifier corresponding to the device identifier generated by the cloud, and write the virtual device identifier into the device identity mapping relationship; A protocol adaptation unit is established, which is used to convert the control commands of the target platform in the standard protocol format into the source protocol format supported by the IoT device; The control commands received by the target platform for the IoT device are converted by the protocol adaptation unit and then sent to the IoT device. The system receives status data returned by the IoT device, converts it through the protocol adaptation unit, and then transmits it back to the target platform.

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

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

Images