Smart home device access method and apparatus

Abstract

The application provides a smart home device access method and device, the method comprising: a user adding a skill through a smart home control center, receiving an authorization request from an automation assistant, matching a corresponding manufacturer configuration based on the authorization request and guiding the user to an authorization page of the manufacturer for authorization after successful matching, the automation assistant initiating a device synchronization request, reading a device list bound by the user, identifying a corresponding device type based on a product identifier, dynamically assembling the device and returning the assembled device to the automation assistant, the automation assistant initiating a state query request, parsing a device identifier list in the state query request and querying a device state based on the device type, the automation assistant issuing a command execution request, parsing command parameters obtained from the command execution request to execute a device command, and reporting the latest state of the device to the automation assistant after the command execution is completed.

Description

Technical Field

[0001] This application relates to the field of smart home technology, and more specifically, to a method and apparatus for accessing smart home devices. Background Technology

[0002] With the rapid development of the smart home ecosystem, automation assistants (such as Google Assistant) need to connect to a massive number of heterogeneous devices. Different manufacturers use proprietary communication protocols, authentication mechanisms, and device models, leading to systemic challenges on the platform side, such as fragmented device access, complex protocol adaptation, and rigid functional expansion.

[0003] Currently, there are three main types of mainstream access solutions: First, each vendor independently develops its own integration services, implementing OAuth authorization, device discovery, status synchronization, and command execution. Second, the platform uniformly encapsulates the core services, but device type identification and capability mapping use hard-coded switch-case logic. Third, matching is based on a fixed list of device templates, with template fields predefined and not dynamically expandable.

[0004] However, among the aforementioned mainstream access solutions, independent integration with vendors leads to redundant development and high maintenance costs; hard-coded device type mapping requires code modification and recompilation for new devices, making it difficult to meet the needs of rapid product category iteration; fixed templates are difficult to adapt to the differences in protocol capabilities between devices of the same type (such as different combinations of support for HLS / WebRTC / progressive_mp4 by cameras), which can easily result in feature reduction or template explosion, all of which affect access efficiency, scalability, and operational reliability in multi-vendor environments. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a smart home device access method and device. By combining configuration-driven PID mapping for multi-vendor authorization, device type identification, device status query, device command execution, and device status reporting, when adding a new device model, only the configuration needs to be modified without changing the code, achieving hot expansion of device types. When adding a new vendor, only one configuration line needs to be added, without modifying the authorization logic code, avoiding redundant development, reducing maintenance costs, and meeting the needs of rapid product category iteration. In addition, the same set of code adapts to the protocol differences of different vendors, eliminating the need to maintain an independent template for each difference point. It can adapt to the protocol capability differences between devices of the same type, improving access efficiency, scalability, and operational reliability in a multi-vendor environment.

[0006] In a first aspect, embodiments of this application provide a method for accessing smart home devices, the method comprising: In response to a user adding a skill through the smart home control center, the system receives an authorization request from the automation assistant, matches the corresponding manufacturer configuration based on the authorization request, and guides the user to the corresponding manufacturer's authorization page for authorization after a successful match. In response to the device synchronization request initiated by the automation assistant, the system reads the list of devices bound by the user, obtains the corresponding product identifier, identifies the corresponding device type based on the product identifier, dynamically assembles the device based on the device type, and returns the assembled device to the automation assistant. In response to the status query request initiated by the automation assistant, the device identifier list in the status query request is parsed, and the corresponding device status is queried based on the device type; In response to the command execution request issued by the automation assistant, the command execution request is parsed to obtain command parameters, and the device command is executed based on the command parameters; After the command is executed, the latest status of the device is obtained and reported to the automation assistant.

[0007] In one possible implementation, the step of matching the corresponding vendor configuration based on the authorization request, and redirecting the user to the corresponding vendor's authorization page for authorization upon successful matching, includes: Parse the client identifier in the authorization request, read the preset vendor constant table, match the corresponding vendor configuration in the vendor constant table according to the client identifier, and construct a redirect response to the automation assistant after a successful match to guide the user to the vendor authorization page of the matched vendor. In response to the user completing account login and authorization on the manufacturer's authorization page, the system verifies the status parameters by calling back the authorization code and status parameters from the manufacturer's server, uses the authorization code to exchange for the corresponding access token and refresh token from the manufacturer's authorization page, and writes the user binding information into a preset database.

[0008] In one possible implementation, in response to the automation assistant initiating a device synchronization request, reading the user-bound device list and obtaining the corresponding product identifier, and identifying the corresponding device type based on the product identifier, includes: In response to the device synchronization request initiated by the automation assistant, the system reads the list of devices bound to the user from the database and iterates through each device to read the corresponding product identifier. The product identifier is used to match the product list in the configuration file, and the corresponding device type is identified based on the list of device types matched by the product identifier.

[0009] In one possible implementation, the device type includes at least switch type, camera type, and door lock type; the step of querying the corresponding device status based on the device type includes: When the device type is switch, the online status and switch status of the device are retrieved from the database, and a response is constructed directly. When the device type is a camera, the target playback function is called to obtain the playback address and select the corresponding protocol according to the protocol supported by the device and the current network environment, and then the playback address and the protocol are sent to the automation assistant; When the device type is a door lock, the door lock status is queried from the database and returned to the automation assistant.

[0010] In one possible implementation, parsing the command execution request to obtain command parameters and executing device commands based on the command parameters includes: The target device and command parameters in the command execution request are parsed, and the command parameters are distributed to the command processing layer for execution according to the device type of the target device; Once the command is executed, an execution response is constructed and returned to the automation assistant.

[0011] In one possible implementation, the step of obtaining the latest status of the device after command execution and reporting the latest status of the device to the automation assistant includes: After the command is executed, an asynchronous delayed task is started, and the latest status of the device is queried again after the target delay time. Construct a status report request and report the latest status of the device to the automation assistant.

[0012] In one possible implementation, the method further includes: Select the corresponding message middleware based on the region where the device is located, establish an encrypted connection, and subscribe to the device alarm topic; When a device status change event occurs, an alarm message is published to the message middleware through the device gateway to obtain an MQTT message. The event type in the MQTT message is parsed, and the status of the corresponding device in the database is updated. When the state of the device changes substantially, the latest state of the device is synchronized to the automation assistant.

[0013] Secondly, embodiments of this application also provide a smart home device access device, the device comprising: The authorization module is used to respond to the user adding skills through the smart home control center, receive authorization requests from the automation assistant, match the corresponding manufacturer configuration based on the authorization request, and guide the user to the corresponding manufacturer's authorization page for authorization after successful matching; The identification module is used to respond to the device synchronization request initiated by the automation assistant, read the list of devices bound by the user, obtain the corresponding product identifier, identify the corresponding device type based on the product identifier, dynamically assemble the device based on the device type, and return the assembled device to the automation assistant. The query module is used to respond to the status query request initiated by the automation assistant, parse the list of device identifiers in the status query request, and query the corresponding device status based on the device type; The execution module is used to respond to the command execution request issued by the automation assistant, parse the command execution request to obtain command parameters, and execute device commands based on the command parameters; The reporting module is used to obtain the latest status of the device after the command is executed, and report the latest status of the device to the automation assistant.

[0014] In one possible implementation, the authorization module is specifically used for: Parse the client identifier in the authorization request, read the preset vendor constant table, match the corresponding vendor configuration in the vendor constant table according to the client identifier, and construct a redirect response to the automation assistant after a successful match to guide the user to the vendor authorization page of the matched vendor. In response to the user completing account login and authorization on the manufacturer's authorization page, the system verifies the status parameters by calling back the authorization code and status parameters from the manufacturer's server, uses the authorization code to exchange for the corresponding access token and refresh token from the manufacturer's authorization page, and writes the user binding information into a preset database.

[0015] In one possible implementation, the identification module is specifically used for: In response to the device synchronization request initiated by the automation assistant, the system reads the list of devices bound to the user from the database and iterates through each device to read the corresponding product identifier. The product identifier is used to match the product list in the configuration file, and the corresponding device type is identified based on the list of device types matched by the product identifier.

[0016] In one possible implementation, the device type includes at least switch type, camera type, and door lock type; the query module is specifically used for: When the device type is switch, the online status and switch status of the device are retrieved from the database, and a response is constructed directly. When the device type is a camera, the target playback function is called to obtain the playback address and select the corresponding protocol according to the protocol supported by the device and the current network environment, and then the playback address and the protocol are sent to the automation assistant; When the device type is a door lock, the door lock status is queried from the database and returned to the automation assistant.

[0017] In one possible implementation, the execution module is specifically used for: The target device and command parameters in the command execution request are parsed, and the command parameters are distributed to the command processing layer for execution according to the device type of the target device; Once the command is executed, an execution response is constructed and returned to the automation assistant.

[0018] In one possible implementation, the reporting module is specifically used for: After the command is executed, an asynchronous delayed task is started, and the latest status of the device is queried again after the target delay time. Construct a status report request and report the latest status of the device to the automation assistant.

[0019] In one possible implementation, the device further includes: The connection module is used to select the corresponding message middleware according to the region where the device is located, establish an encrypted connection, and subscribe to device alarm topics. The update module is used to publish an alarm message to the message middleware through the device gateway when a device status change event occurs, obtain an MQTT message, parse the event type in the MQTT message, and update the status of the corresponding device in the database. The synchronization module is used to synchronize the latest state of the device to the automation assistant when the state change of the device is a substantial change.

[0020] Thirdly, embodiments of this application provide an electronic device, including: a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the smart home device access method as described in any of the first aspects.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the smart home device access method described in any one of the first aspects.

[0022] This application provides a smart home device access method and apparatus. In response to a user adding a skill through a smart home control center, the method receives an authorization request from an automation assistant, matches the corresponding manufacturer configuration based on the authorization request, and guides the user to the corresponding manufacturer's authorization page for authorization upon successful matching. In response to the automation assistant initiating a device synchronization request, the method reads the user-bound device list, obtains the corresponding product identifier, identifies the corresponding device type based on the product identifier, dynamically assembles the device based on the device type, and returns the assembled device to the automation assistant. In response to the automation assistant initiating a status query request, the method parses the device identifier list in the status query request and queries the corresponding device status based on the device type. In response to the automation assistant issuing a command execution request, the method parses the command execution request to obtain command parameters, executes the device command based on the command parameters, obtains the latest device status after command execution, and reports the latest device status to the automation assistant. This application, by combining configuration-driven PID mapping for multi-vendor authorization, device type identification, device status query, device command execution, and device status reporting, achieves hot expansion of device types by only modifying the configuration when adding a new device model, without changing the code. Similarly, adding a new vendor only requires adding a configuration entry, without modifying the authorization logic code, avoiding redundant development, reducing maintenance costs, and meeting the needs of rapid product category iteration. Furthermore, the same codebase adapts to the protocol differences of different vendors, eliminating the need to maintain independent templates for each difference. This adapts to protocol capability differences between devices of the same type, improving access efficiency, scalability, and operational reliability in multi-vendor environments.

[0023] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart of a smart home device access method provided according to an embodiment of this application; Figure 2This is a flowchart illustrating the process of multi-vendor licensing and device binding; Figure 3 This is a flowchart illustrating the process of querying device status; Figure 4 This is a flowchart illustrating the process of delayed status reporting and MQTT event-driven synchronization. Figure 5 This is a schematic diagram of the structure of a smart home device access device provided according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0027] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0029] Given the rapid development of the smart home ecosystem, automation assistants (such as Google Assistant) need to connect to a massive number of heterogeneous devices. Different manufacturers use proprietary communication protocols, authentication mechanisms, and device models, leading to systemic challenges on the platform side, such as fragmented device access, complex protocol adaptation, and rigid functional expansion.

[0030] Currently, there are three main types of mainstream access solutions: First, each vendor independently develops its own integration services, implementing OAuth authorization, device discovery, status synchronization, and command execution. Second, the platform uniformly encapsulates the core services, but device type identification and capability mapping use hard-coded switch-case logic. Third, matching is based on a fixed list of device templates, with template fields predefined and not dynamically expandable.

[0031] However, among the aforementioned mainstream access solutions, independent integration with vendors leads to redundant development and high maintenance costs; hard-coded device type mapping requires code modification and recompilation for new devices, making it difficult to meet the needs of rapid product category iteration; fixed templates are difficult to adapt to the differences in protocol capabilities between devices of the same type (such as different combinations of support for HLS / WebRTC / progressive_mp4 by cameras), which can easily result in feature reduction or template explosion, all of which affect access efficiency, scalability, and operational reliability in multi-vendor environments.

[0032] To address this issue, this application provides a smart home device access method and apparatus. By combining configuration-driven PID mapping, it enables multi-vendor authorization, device type identification, device status query, device command execution, and device status reporting. When adding a new device model, only the configuration needs to be modified, without changing the code, achieving hot expansion of device types. When adding a new vendor, only one configuration line needs to be added, without modifying the authorization logic code, avoiding redundant development, reducing maintenance costs, and meeting the needs of rapid product category iteration. In addition, the same code adapts to the protocol differences of different vendors, eliminating the need to maintain independent templates for each difference point. It can adapt to the protocol capability differences between devices of the same type, improving access efficiency, scalability, and operational reliability in multi-vendor environments.

[0033] Figure 1 This is a flowchart of a smart home device access method provided according to an embodiment of this application. For example... Figure 1 As shown in the embodiments of this application, the smart home device access method may specifically include: S101. In response to the user adding a skill through the smart home control center, receive an authorization request from the automation assistant, match the corresponding manufacturer configuration based on the authorization request, and guide the user to the corresponding manufacturer's authorization page for authorization after successful matching.

[0034] S102. In response to the device synchronization request initiated by the automation assistant, read the list of devices bound by the user, obtain the corresponding product identifier, identify the corresponding device type based on the product identifier, dynamically assemble the device based on the device type, and return the assembled device to the automation assistant.

[0035] S103. In response to the status query request initiated by the automation assistant, parse the list of device identifiers in the status query request, and query the corresponding device status based on the device type.

[0036] S104. Respond to the command execution request issued by the automation assistant, parse the command execution request to obtain the command parameters, and execute the device command based on the command parameters.

[0037] S105. After the command is executed, obtain the latest status of the device and report the latest status of the device to the automation assistant.

[0038] The aforementioned smart home device access method combines configuration-driven PID mapping for multi-vendor authorization, device type identification, device status query, device command execution, and device status reporting. When adding a new device model, only the configuration needs modification, not the code, achieving hot expansion of device types. Adding a new vendor also requires only adding a configuration entry, without modifying the authorization logic code, avoiding redundant development, reducing maintenance costs, and meeting the needs of rapid product category iteration. Furthermore, the same codebase adapts to the protocol differences of different vendors, eliminating the need to maintain independent templates for each difference. This adapts to protocol capability differences between similar devices, improving access efficiency, scalability, and operational reliability in multi-vendor environments.

[0039] The exemplary steps described above in the embodiments of this application are illustrated below with specific examples: S101 responds to the user adding skills through the smart home control center, receives authorization requests from the automation assistant, matches the corresponding manufacturer configuration based on the authorization request, and guides the user to the corresponding manufacturer's authorization page for authorization after successful matching.

[0040] In this embodiment, the authorization request carries a client identifier (client_id). When a user adds a skill through the smart home control center (described in this application using the Google Home App as an example), the access proxy service (corresponding to the Google routing layer) receives the authorization request from the automation assistant (described in this application using Google Assistant as an example), matches the corresponding manufacturer configuration according to the authorization request, and, upon successful matching, redirects the user to the corresponding manufacturer's authorization page for authorization and subsequent processing. For example, as Figure 2 As shown, when a user adds a skill through the Google Home App, Google Assistant sends an authorization request to the access proxy service (e.g., GET / oauth2 / google / authorize), with the client_id parameter included in the request.

[0041] Optionally, when matching the corresponding vendor configuration based on the authorization request and redirecting the user to the corresponding vendor's authorization page for authorization after a successful match, the client identifier in the authorization request is parsed, a preset vendor constant table is read, the corresponding vendor configuration is matched in the vendor constant table according to the client identifier, and a redirection response is constructed to the automation assistant after a successful match, redirecting the user to the matching vendor's authorization page; in response to the user completing account login and authorization on the vendor authorization page, the authorization code and status parameters are called back from the vendor's server, the status parameters are verified, the authorization code is used to exchange for the corresponding access token and refresh token from the vendor authorization page, and the user binding information is written to a preset database.

[0042] Among them, user binding information refers to the binding information between the user and the device; client identifier mapping is centrally maintained in the vendor constant table; vendor configuration includes at least the vendor name, front-end authorization page address, ClientSecret, and authorization callback address. Therefore, the client identifier mapping of each vendor is centrally maintained in the constant configuration, and when adding a new vendor, only one configuration record needs to be added, without modifying the authorization logic code.

[0043] Specifically, for example, such as Figure 2 As shown, the access proxy service reads the preset vendor constant table (constant.go) and matches the corresponding vendor configuration based on the client_id, including: vendor name, front-end authorization page address, ClientSecret, authorization callback address, etc. When a match is successful, a 302 redirect response is constructed to the vendor page, guiding the user to the corresponding vendor's authorization page. After the user completes account login and authorization on the vendor's authorization page, the vendor server (i.e., the access proxy service) calls back to the access proxy service, carrying the authorization code and state parameter. The access proxy service verifies the state parameter to prevent CSRF attacks, exchanges the authorization code with the vendor's token service for an access token and refresh token (access_token), returns the access_token, and writes the user and device binding information to the Redis database.

[0044] S102, in response to the device synchronization request initiated by the automation assistant, read the list of devices bound by the user and obtain the corresponding product identifier, identify the corresponding device type based on the product identifier, dynamically assemble the device based on the device type, and return the assembled device to the automation assistant.

[0045] In this embodiment, the device types include at least switch types, camera types, and door lock types. When the automation assistant initiates a device synchronization request, it reads the user-bound device list to obtain product identifiers, identifies the device type based on the product identifiers, dynamically assembles the device capabilities (traits) and attributes supported by the device based on the device type, and returns the assembled device to the intelligent voice assistant to complete device discovery for subsequent processing.

[0046] In some implementations, in response to an automation assistant initiating a device synchronization request, the system reads the list of user-bound devices from the database and iterates through each device to read its corresponding product identifier. Based on the product identifier, it matches the product list in the configuration file and identifies the corresponding device type based on the list of device types matched by the product identifier. Based on the identified device type, it dynamically assembles the device capabilities and attributes supported by the device and returns the assembled device to the automation assistant, thus completing device discovery.

[0047] Specifically, for example, when Google Assistant initiates a device synchronization request (SYNC intent), the protocol adaptation engine (google_assist layer) reads the list of devices bound to the user from the Redis database, iterates through each device to read its product ID (PID), and queries the PID mapping table in the configuration (DevPid field in config.json) to match the device type according to the following rules: when the PID falls in the SingleSocket / MultipleSocket / Light list, it is identified as an Outlet type, i.e., a switch type (supporting the OnOff trait); when the PID falls in the DoorLock list, it is identified as a DoorLock type, i.e., a door lock type (supporting the LockUnlock trait); when the PID does not match the above lists, it is identified by default as a CameraStream type, i.e., a camera type (supporting the CameraStream trait).

[0048] Continuing, based on the identified device type, the system dynamically assembles the device capabilities traits and attributes supported by that device. Specifically: for the `Outlet` type, `action.devices.traits.OnOff` is set, populating the online and on states; for the `CameraStream` type, `action.devices.traits.CameraStream` is set, populating the list of supported protocols (`cameraStreamSupportedProtocols`: HLS / WebRTC / progressive_mp4), the camera preview image address, and whether token authentication is required; for the `DoorLock` type, `action.devices.traits.LockUnlock` is set, populating the `isLocked` state and whether PIN code protection is supported. Finally, the assembled device list is returned to Google Assistant, completing the device discovery process.

[0049] Therefore, device type identification is entirely configuration-driven. When adding a new device model, you only need to append the corresponding PID value to the PID list in config.json without modifying the code logic, thus achieving hot expansion of device types.

[0050] S103, in response to the status query request initiated by the automation assistant, parses the list of device identifiers in the status query request, and queries the corresponding device status based on the device type.

[0051] In this embodiment of the application, when the automation assistant initiates a status query request, it parses the device identifier list in the status query request and queries the corresponding device status based on the device type for subsequent processing. For example, as Figure 3 As shown.

[0052] Optionally, when querying the corresponding device status based on device type, if the device type is a switch, the online status and on / off status of the device are retrieved from the database, and a response is constructed directly; if the device type is a camera, the target playback function is called to obtain the playback address and select the corresponding protocol according to the protocol supported by the device and the current network environment, and the playback address and protocol are sent to the automation assistant; if the device type is a door lock, the door lock status is retrieved from the database, and the door lock status is returned to the automation assistant.

[0053] Specifically, for example, such as Figure 3As shown, Google Assistant initiates a status query request (QUERYintent) to retrieve the device list and status. The protocol adaptation engine parses the device ID list in the request. For Outlet type devices, it queries Redis to obtain the device's online status (on) and on / off status (on / off) and directly constructs the response. For CameraStream type devices, a live stream URL needs to be generated. The protocol adaptation engine calls the GetPlayUrl / GetPlayUrlV2 function in the command processing layer. This function performs the following logic: it first attempts to obtain the playback URL using an Admin Token, which has higher privileges and supports more protocols. If the Admin Token is unavailable, it falls back to obtaining it using User Credentials. Based on the device's supported protocols and the current network environment, it automatically selects either HLS or WebRTC protocol and returns the generated playback URL and protocol type (i.e., returns streamUrl and protocols). For DoorLock type devices, the isLocked value is returned by combining the door lock status stored in Redis with the latest MQTT event status. If the device is in a low-power (deep sleep) state, the offline status (isLocked) is returned along with the reason for the offline status.

[0054] Therefore, the protocol capabilities of the same type of device (camera) may differ between different manufacturers. By automatically selecting the protocol at the command layer and using dual-channel authentication (Admin Token / User Credential), the protocol differences between manufacturers are masked.

[0055] S104 responds to the command execution request issued by the automation assistant, parses the command execution request to obtain command parameters, and executes the device command based on the command parameters.

[0056] In this embodiment of the application, when the automation assistant issues a command execution request, i.e., a device control instruction, the command execution request is parsed to obtain command parameters, and the device command is executed based on the command parameters for subsequent processing. For example, as Figure 4 As shown.

[0057] In some implementations, the target device and command parameters in the command execution request are parsed, and the command parameters are distributed to the command processing layer for execution according to the device type of the target device. After the command execution is completed, an execution response is constructed and returned to the automation assistant. The execution response includes at least whether the execution was successful and the status of the affected device.

[0058] Specifically, Google Assistant initiates an EXECUTE intent, the request body of which includes the target device and command parameters (such as `on: true` for `OnOff` and `lock: true` for `LockUnlock`). The protocol adaptation engine parses the command and distributes it to the command processing layer according to the device type: For the `OnOff` switch command (corresponding to the switch type): `OnOffController` is called to send the switch control instruction to the device gateway, and the execution result is awaited. For the `CameraStream` camera command (corresponding to the camera type): `GetPlayUrl` is called to generate the playback URL (same steps as above). For the `LockUnlock` command (corresponding to the lock type): If the device has PIN code protection enabled (set in `VoiceConfig`), the request is verified to ensure that the correct PIN code is included; if the PIN is incorrect, `pinIncorrect` is returned; if no PIN is provided, `challengeNeeded(pinNeeded)` is returned; if the PIN verification is successful, the lock control instruction is invoked. Finally, after the command execution is complete, the protocol adaptation engine constructs an execution response and returns it to Google Assistant, including whether the execution was successful, the status of the affected devices, etc.

[0059] S105: After the command is executed, obtain the latest status of the device and report the latest status of the device to the automation assistant.

[0060] In this embodiment of the application, after the command is executed, the latest status of the device is reported to the automation assistant. For example, such as Figure 4 As shown.

[0061] In some implementations, after the command is executed, an asynchronous delayed task is started, and after a target delay time (via the command processing layer or the database), the latest status of the device is queried again; a status report request is constructed, and the latest status of the device is reported to the automation assistant.

[0062] Specifically, for example, after the command is executed, the system does not immediately report the final state of the device. Instead, it starts an asynchronous delayed task (goroutine, for example, delayed for 2 seconds) to delay the reporting path (triggered by the command). After the 2-second delay, the asynchronous task queries the latest state of the device again (through the command layer or Redis), constructs the latest state Report State request, and reports the Report State to Google Assistant through the Google Home Graph API.

[0063] It should be noted that the state of the device will not be stable instantly after executing a command (for example, it takes time for a door lock to go from unlocking to locking). Immediate reporting may report an intermediate state, while delayed reporting can avoid the state transition period, ensure that a stable state is reported, and avoid flickering on the speaker display.

[0064] The smart home device access method provided in this application responds to the user adding skills through the smart home control center, receiving an authorization request from an automation assistant, matching the corresponding manufacturer configuration based on the authorization request, and guiding the user to the corresponding manufacturer's authorization page for authorization after successful matching; responding to the automation assistant initiating a device synchronization request, reading the list of devices bound by the user, obtaining the corresponding product identifier, identifying the corresponding device type based on the product identifier, dynamically assembling the device based on the device type, and returning the assembled device to the automation assistant; responding to the automation assistant initiating a status query request, parsing the list of device identifiers in the status query request, querying the corresponding device status based on the device type; responding to the automation assistant issuing a command execution request, parsing the command execution request to obtain command parameters, executing the device command based on the command parameters, obtaining the latest status of the device after command execution, and reporting the latest status of the device to the automation assistant. This smart home device access method, by combining configuration-driven PID... The mapping mechanism handles multi-vendor authorization, device type identification, device status query, device command execution, and device status reporting. When adding a new device model, only configuration modifications are needed, without changing the code, enabling hot expansion of device types. Adding a new vendor also requires only adding a configuration entry, without modifying the authorization logic code, avoiding redundant development, reducing maintenance costs, and meeting the needs of rapid product category iteration. Furthermore, the same codebase adapts to the protocol differences of different vendors, eliminating the need to maintain independent templates for each difference. This adapts to protocol capability differences between devices of the same type, improving access efficiency, scalability, and operational reliability in multi-vendor environments.

[0065] Furthermore, the system selects the corresponding message middleware based on the region where the device is located, establishes an encrypted connection, and subscribes to device alarm topics. When a device status change event occurs, the system publishes an alarm message to the message middleware through the device gateway to obtain an MQTT message, parses the event type in the MQTT message, and updates the corresponding device status in the database. When the device status change is a substantial change, the system synchronizes the latest device status to the automation assistant.

[0066] Specifically, upon system startup, the state management layer selects an MQTT Broker message middleware based on the device region, establishes a TLS encrypted connection, and subscribes to the device alarm topic ( / device / {sn} / alarmEvent). When a device experiences a state change event (such as a door lock being opened / closed, or a device alarm), the device gateway publishes an alarm message (i.e., the alarm event / device / {sn} / alarmEvent) to the MQTT Broker. Upon receiving the MQTT message, the state management layer parses the event type (DoorOpen / DoorClose / RemoteLocking / RemoteUnlock) and updates the corresponding device's status field, Report State, in Redis. If the event causes a substantial change in the device's state (such as changing from locked to unlocked), it triggers Google Home Graph status reporting, synchronizing the latest Report State to Google Assistant.

[0067] Therefore, by combining MQTT event-driven and delayed reporting, real-time push of state changes is guaranteed (MQTT event triggering), while avoiding state jitter after command execution (delayed reporting filters transition states).

[0068] Furthermore, middleware is set up at the HTTP routing layer. This middleware reads the target fields from the request headers of all requests and selects the decryption method based on the encryption type. After business processing is complete, the middleware captures the response body, encrypts it according to the encryption type specified in the request header, sets the new content type and length, and then returns it to the client. The target fields include an encryption type identifier, a timestamp factor, and a request factor. The key is derived by concatenating the timestamp factor and the request factor.

[0069] Specifically, the entire process in this application involves encrypted transmission. At the HTTP routing layer, all requests first pass through an encryption middleware (JFEncMiddleware). The middleware reads the encryption type identifier (JFTECH-EV), timestamp factor (JFTECH-TIME), and request factor (JFTECH-REQ) from the request header. The middleware selects the decryption method based on the encryption type: Type 1 uses pure XOR decryption; Type 2 first decodes using Base64, then decrypts using XOR. The key is derived from the concatenation of the timestamp factor and the request factor, ensuring a unique key for each request. The decrypted request body replaces the original request body and continues downstream processing. After business processing is complete, the middleware captures the response body. If the response is in JSON format, it encrypts the response body according to the encryption type specified in the request header, sets a new Content-Type and Content-Length, and returns it to the client.

[0070] Therefore, by using lightweight symmetric encryption (XOR + Base64) and dynamically derived keys, only the JSON response body is encrypted, while non-JSON responses (such as streaming media data) are not encrypted, thus balancing security and performance.

[0071] In summary, this application automatically categorizes devices into types such as Outlet, CameraStream, and DoorLock using the PID list maintained in config.json, and dynamically assembles the traits and attributes required by the Google Home Skill protocol based on the type. Adding a new device model only requires modifying the configuration, without changing the code, achieving hot expansion of device types and directly solving the problem of rapid expansion of device types from multiple vendors. The mapping relationships of client_id, authorization page address, and ClientSecret for each vendor are centrally maintained in the constant configuration. When an authorization request arrives, it is automatically routed to the corresponding vendor's authorization process based on the client_id. Adding a new vendor only requires adding a configuration entry, without modifying the authorization logic code. The final status is reported after a 2-second delay after command execution (avoiding the status transition period). Spontaneous device status changes are pushed in real-time via MQTT alarm events. These two mechanisms complement each other, avoiding display flickering on the speaker due to status jitter and ensuring real-time synchronization of non-command-triggered status changes. Camera devices automatically select the HLS / WebRTC protocol based on the manufacturer's capabilities, prioritizing a dual-channel authentication mechanism using administrator tokens and fallback to user credentials. The same codebase adapts to protocol differences across manufacturers, eliminating the need to maintain separate templates for each variation. A request / response body encryption middleware is added to the HTTP routing layer, supporting both XOR and XOR+Base64 modes. The key is dynamically derived from a timestamp and request factor, encrypting only the JSON response body and not streaming media data, balancing security and transmission performance. PIN code protection for door lock devices can be enabled / disabled. During voice control, if PIN protection is enabled, the PIN code is verified. If no PIN is provided, `challengeNeeded(pinNeeded)` is returned; if the PIN is incorrect, `pinIncorrect` is returned, forming a complete challenge-response security loop.

[0072] Figure 5 This is a structural schematic diagram of a smart home device access device provided according to an embodiment of this application; as shown below. Figure 5 As shown, the smart home device access device 500 of this application embodiment may specifically include: The authorization module 501 is used to respond to the user adding skills through the smart home control center, receive authorization requests from the automation assistant, match the corresponding manufacturer configuration based on the authorization request, and guide the user to the corresponding manufacturer's authorization page for authorization after successful matching; The identification module 502 is used to respond to the device synchronization request initiated by the automation assistant, read the list of devices bound by the user, obtain the corresponding product identifier, identify the corresponding device type based on the product identifier, dynamically assemble the device based on the device type, and return the assembled device to the automation assistant. The query module 503 is used to respond to the status query request initiated by the automation assistant, parse the list of device identifiers in the status query request, and query the corresponding device status based on the device type. The execution module 504 is used to respond to the command execution request issued by the automation assistant, parse the command execution request to obtain the command parameters, and execute the device command based on the command parameters; The reporting module 505 is used to obtain the latest status of the device after the command is executed and report the latest status of the device to the automation assistant.

[0073] In one possible implementation, the authorization module is specifically used for: Parse the client identifier in the authorization request, read the preset vendor constant table, match the corresponding vendor configuration in the vendor constant table according to the client identifier, and construct a redirect response to the automation assistant after a successful match, so as to guide the user to the vendor authorization page of the matched vendor. In response to the user completing account login and authorization on the manufacturer's authorization page, the system receives a callback from the manufacturer's server with the authorization code and status parameters. The status parameters are then verified, the authorization code is used to obtain the corresponding access token and refresh token from the manufacturer's authorization page, and the user's binding information is written to a preset database.

[0074] In one possible implementation, the identification module is specifically used for: In response to the device synchronization request initiated by the automation assistant, the system reads the list of devices bound to the user from the database and iterates through each device to read the corresponding product identifier. The system matches the product identifier against the product list in the configuration file, and identifies the corresponding device type based on the list of device types matched by the product identifier.

[0075] In one possible implementation, the device types include at least switch types, camera types, and door lock types; the query module is specifically used for: When the device type is switch, retrieve the device's online status and switch status from the database, and construct the response directly. When the device type is a camera, the target playback function is called to obtain the playback address and select the corresponding protocol according to the protocol supported by the device and the current network environment, and then the playback address and protocol are sent to the automation assistant; When the device type is door lock, query the door lock status from the database and return the door lock status to the automation assistant.

[0076] In one possible implementation, the execution module is specifically used for: Parse the target device and command parameters in the command execution request, and distribute the command parameters to the command processing layer for execution according to the device type of the target device; Once the command is executed, an execution response is constructed and returned to the automation assistant.

[0077] In one possible implementation, the reporting module is specifically used for: After the command is executed, an asynchronous delayed task is started, and the latest status of the device is queried again after the target delay time. Build a status report request and report the latest status of the equipment to the automation assistant.

[0078] In one possible implementation, the device further includes: The connection module is used to select the corresponding message middleware according to the region where the device is located, establish an encrypted connection, and subscribe to device alarm topics. The update module is used to publish an alarm message to the message middleware through the device gateway when a device status change event occurs, obtain an MQTT message, parse the event type in the MQTT message, and update the status of the corresponding device in the database. The synchronization module is used to synchronize the latest status of the device with the automation assistant when the device's status changes substantially.

[0079] The smart home device access device provided in this application embodiment responds to the user adding skills through the smart home control center, receiving an authorization request from an automation assistant, matching the corresponding manufacturer configuration based on the authorization request, and guiding the user to the corresponding manufacturer's authorization page for authorization after successful matching. Responding to the automation assistant initiating a device synchronization request, it reads the list of devices bound by the user, obtains the corresponding product identifier, identifies the corresponding device type based on the product identifier, dynamically assembles the device based on the device type, and returns the assembled device to the automation assistant. Responding to the automation assistant initiating a status query request, it parses the list of device identifiers in the status query request and queries the corresponding device status based on the device type. Responding to the automation assistant issuing a command execution request, it parses the command execution request to obtain command parameters, executes the device command based on the command parameters, obtains the latest device status after command execution, and reports the latest device status to the automation assistant. The smart home device access device of this application, through configuration-driven PID mapping, performs multi-vendor authorization, device type identification, device status query, device command execution, and device status reporting. When adding a new device model, only the configuration needs to be modified, without changing the code, achieving hot expansion of device types. When adding a new vendor, only one configuration line needs to be added, without modifying the authorization logic code, avoiding redundant development, reducing maintenance costs, and meeting the needs of rapid product category iteration. In addition, the same code adapts to the protocol differences of different vendors, eliminating the need to maintain an independent template for each difference point. It can adapt to the protocol capability differences between devices of the same type, improving access efficiency, scalability, and operational reliability in multi-vendor environments.

[0080] like Figure 6 As shown in the embodiment of this application, an electronic device 600 includes a processor 601, a memory 602, and a bus. The memory 602 stores machine-readable instructions executable by the processor 601. When the electronic device is running, the processor 601 communicates with the memory 602 via the bus, and the processor 601 executes the machine-readable instructions to perform the steps of the smart home device access method described above.

[0081] Specifically, the memory 602 and processor 601 mentioned above can be general-purpose memory and processor, without any specific limitations. When the processor 601 runs the computer program stored in the memory 602, it can execute the above-mentioned smart home device access method.

[0082] Corresponding to the above-described smart home device access method, this application embodiment also provides a computer-readable storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described smart home device access method.

[0083] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0084] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0085] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0086] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the deployment methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A method for connecting smart home devices, characterized in that, The method includes: In response to a user adding a skill through the smart home control center, the system receives an authorization request from the automation assistant, matches the corresponding manufacturer configuration based on the authorization request, and guides the user to the corresponding manufacturer's authorization page for authorization after a successful match. In response to the device synchronization request initiated by the automation assistant, the system reads the list of devices bound by the user, obtains the corresponding product identifier, identifies the corresponding device type based on the product identifier, dynamically assembles the device based on the device type, and returns the assembled device to the automation assistant. In response to the status query request initiated by the automation assistant, the device identifier list in the status query request is parsed, and the corresponding device status is queried based on the device type; In response to the command execution request issued by the automation assistant, the command execution request is parsed to obtain command parameters, and the device command is executed based on the command parameters; After the command is executed, the latest status of the device is obtained and reported to the automation assistant.

2. The method according to claim 1, characterized in that, The step of matching the corresponding vendor configuration based on the authorization request, and redirecting the user to the corresponding vendor's authorization page for authorization upon successful matching, includes: Parse the client identifier in the authorization request, read the preset vendor constant table, match the corresponding vendor configuration in the vendor constant table according to the client identifier, and construct a redirect response to the automation assistant after a successful match to guide the user to the vendor authorization page of the matched vendor. In response to the user completing account login and authorization on the manufacturer's authorization page, the system verifies the status parameters by calling back the authorization code and status parameters from the manufacturer's server, uses the authorization code to exchange for the corresponding access token and refresh token from the manufacturer's authorization page, and writes the user binding information into a preset database.

3. The method according to claim 2, characterized in that, In response to the automation assistant initiating a device synchronization request, the system reads the list of devices bound to the user, obtains the corresponding product identifier, and identifies the corresponding device type based on the product identifier, including: In response to the device synchronization request initiated by the automation assistant, the system reads the list of devices bound to the user from the database and iterates through each device to read the corresponding product identifier. The product identifier is used to match the product list in the configuration file, and the corresponding device type is identified based on the list of device types matched by the product identifier.

4. The method according to claim 3, characterized in that, The device types include at least switch types, camera types, and door lock types; the process of querying the corresponding device status based on the device type includes: When the device type is switch, the online status and switch status of the device are retrieved from the database, and a response is constructed directly. When the device type is a camera, the target playback function is called to obtain the playback address and select the corresponding protocol according to the protocol supported by the device and the current network environment, and then the playback address and the protocol are sent to the automation assistant; When the device type is a door lock, the door lock status is queried from the database and returned to the automation assistant.

5. The method according to claim 1, characterized in that, The step of parsing the command execution request to obtain command parameters and executing device commands based on the command parameters includes: The target device and command parameters in the command execution request are parsed, and the command parameters are distributed to the command processing layer for execution according to the device type of the target device; Once the command is executed, an execution response is constructed and returned to the automation assistant.

6. The method according to claim 2, characterized in that, The step of obtaining the latest status of the device after the command is executed and reporting the latest status of the device to the automation assistant includes: After the command is executed, an asynchronous delayed task is started, and the latest status of the device is queried again after the target delay time. Construct a status report request and report the latest status of the device to the automation assistant.

7. The method according to claim 6, characterized in that, The method further includes: Select the corresponding message middleware based on the region where the device is located, establish an encrypted connection, and subscribe to the device alarm topic; When a device status change event occurs, an alarm message is published to the message middleware through the device gateway to obtain an MQTT message. The event type in the MQTT message is parsed, and the status of the corresponding device in the database is updated. When the state of the device changes substantially, the latest state of the device is synchronized to the automation assistant.

8. A smart home device access device, characterized in that, The device includes: The authorization module is used to respond to the user adding skills through the smart home control center, receive authorization requests from the automation assistant, match the corresponding manufacturer configuration based on the authorization request, and guide the user to the corresponding manufacturer's authorization page for authorization after successful matching; The identification module is used to respond to the device synchronization request initiated by the automation assistant, read the list of devices bound by the user, obtain the corresponding product identifier, identify the corresponding device type based on the product identifier, dynamically assemble the device based on the device type, and return the assembled device to the automation assistant. The query module is used to respond to the status query request initiated by the automation assistant, parse the list of device identifiers in the status query request, and query the corresponding device status based on the device type; The execution module is used to respond to the command execution request issued by the automation assistant, parse the command execution request to obtain command parameters, and execute device commands based on the command parameters; The reporting module is used to obtain the latest status of the device after the command is executed, and report the latest status of the device to the automation assistant.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the smart home device access method as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the smart home device access method as described in any one of claims 1 to 7.

Images