Vehicle-home interconnection method, device, server, storage medium and program product

Abstract

The application provides a vehicle-home interconnection method, device, server, storage medium and program product. The method is applied to a cloud server, and includes the following steps: after receiving a home appliance control request sent by a vehicle, first, the corresponding brand open platform is located according to a home appliance association identifier, and a current state of the home appliance is obtained; then, the state and the control parameter are verified for legality in combination with a preset mutual exclusion logic; after the verification, an adapted control instruction is generated according to an interface format of a target brand platform, and is sent to the corresponding platform for execution. By using the scheme, unified access and control of multiple brand home appliances can be realized, the instruction compatibility, the state judgment accuracy and the response timeliness are improved, and the sending of invalid instructions is reduced.

Description

Technical Field

[0001] This invention relates to the field of home appliance control technology, specifically to a method, device, server, storage medium, and program product for vehicle-home interconnection. Background Technology

[0002] With the rapid development of information technology, connected vehicles and connected home appliances are gradually entering people's lives. The concept of vehicle-home interconnection has emerged, aiming to use Internet technology to connect home appliances with vehicle data, enabling control of home devices from the vehicle and monitoring of vehicle status from the home.

[0003] However, the current smart home appliance market is saturated with brands, each employing unique object model designs to highlight their product features and technological advantages. For example, in temperature control, some brands use integers to represent temperature settings with an adjustment step of 1°C, while others may use floating-point numbers with an adjustment step of 0.5°C. Similarly, in fan speed settings, some brands adjust fan speed in steps of 1, while others use a range of speed levels (low, medium, high). This difference in object models between brands presents significant compatibility challenges when vehicles attempt to control smart home appliances from different brands.

[0004] Therefore, improving the compatibility and feedback consistency of cross-brand control in scenarios involving multiple brands of home appliances is an urgent problem to be solved. Summary of the Invention

[0005] This application provides a method, device, server, storage medium, and program product for vehicle-home interconnection to solve the aforementioned technical problems. This solution targets cloud-based vehicle-home interconnection scenarios, uniformly processing appliance control requests initiated from the vehicle side. In the control process for appliances from different brands, it combines device status, control semantics, and brand platform-side control requirements for collaborative judgment and adaptation. This achieves consistent control interaction and more efficient command processing under multi-brand appliance access conditions, improving cross-brand appliance control compatibility and the timeliness of feedback processing.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] Firstly, this application discloses a method for vehicle-to-home interconnection, applied to a cloud server, the method comprising:

[0008] The system acquires control commands sent by the vehicle-side terminal for controlling home appliances, the control commands including home appliance association identifiers and control parameters;

[0009] Obtain the current device status of the home appliance from the open platform of the brand to which the home appliance association identifier belongs;

[0010] Based on preset mutual exclusion logic rules, determine whether the current device state and the control parameters are mutually exclusive;

[0011] If no mutual exclusion exists, then based on the format requirements of the brand open platform, instructions are generated and issued according to the home appliance association identifier and the control parameters;

[0012] The instruction is sent to the brand open platform, and the instruction is used to instruct the brand open platform to control the home appliances.

[0013] Furthermore, the method also includes:

[0014] If mutual exclusion exists, a response message is generated to indicate a command conflict;

[0015] The response message is sent to the vehicle-side terminal.

[0016] Furthermore, control commands from different home appliance brands use the same format.

[0017] Furthermore, the method also includes:

[0018] Receive the error code sent by the brand's open platform;

[0019] Based on the preset mapping relationship between error codes of each brand and unified error codes, the error codes are converted into response error codes at the vehicle end;

[0020] The response error code is sent to the vehicle-side terminal.

[0021] Furthermore, before determining whether the current device state and the control parameters are mutually exclusive, the method further includes:

[0022] Based on the appliance association identifier, determine the mutual exclusion logic rules of the brand to which the appliance association identifier belongs.

[0023] Furthermore, the appliance-associated identifier is a vehicle identifier, and the method further includes:

[0024] Based on the pre-set mapping relationship between vehicle identifiers and home appliance identifiers, determine the home appliance identifier corresponding to the vehicle identifier;

[0025] The address of the brand's open platform is determined based on the appliance's identifier.

[0026] Secondly, this application provides a vehicle-home interconnection device, the device comprising:

[0027] The acquisition module is used to acquire control commands sent by the vehicle-side terminal for controlling home appliances. The control commands include home appliance association identifiers and control parameters.

[0028] The status query module is used to obtain the current device status of the home appliance from the open platform of the brand to which the home appliance association identifier belongs;

[0029] The mutual exclusion verification module is used to determine whether the current device state and the control parameters are mutually exclusive according to preset mutual exclusion logic rules.

[0030] The format conversion module is used to generate and issue instructions based on the format requirements of the brand open platform, the appliance association identifier, and the control parameters, if no mutual exclusion exists.

[0031] The sending module is used to send the issued instruction to the brand open platform, and the issued instruction is used to instruct the brand open platform to control the home appliance.

[0032] Thirdly, this application provides a server, including: a memory and a processor;

[0033] The memory stores computer-executed instructions;

[0034] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any of the first aspects.

[0035] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0036] Fifthly, this application provides a computer program product including a computer program that, when executed by a processor, implements the method described in any of the first aspects.

[0037] This application provides a method, device, server, storage medium, and program product for vehicle-home interconnection. The method includes: acquiring control commands sent by a vehicle for controlling home appliances; obtaining the current device status of the home appliance from the open platform of the brand to which the home appliance's association identifier belongs; determining whether the current device status and control parameters are mutually exclusive based on preset mutual exclusion logic rules; and generating and sending commands based on the home appliance's association identifier and control parameters according to the format requirements of the brand open platform when no mutual exclusion exists. This solution can uniformly verify, semantically connect, and adapt the control requests of home appliances from different brands in the cloud, thereby improving cross-brand control compatibility and reducing control failures, feedback delays, and maintenance complexity caused by state conflicts or platform differences. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0039] Figure 1 This is a schematic diagram of the vehicle-home interconnection method provided in this application;

[0040] Figure 2 This is an architecture diagram of the vehicle-home interconnection adapter provided in this application;

[0041] Figure 3 This application provides a schematic diagram of the command control flow for vehicle-home interconnection.

[0042] Figure 4 This is a schematic diagram illustrating the status reporting process for smart home appliances connected to the vehicle, as provided in this application.

[0043] Figure 5 This is a schematic diagram of the server structure provided in this application.

[0044] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0046] Vehicle-to-home (V2X) technology is typically used in remote collaborative control scenarios between vehicles and smart home devices, involving the interconnection of intelligent connected vehicles, cloud service platforms, branded home appliance open platforms, and various smart home appliances within the home. In typical applications, users can issue home appliance control requests via in-vehicle voice assistants, central control screens, or compatible mobile terminals while commuting or parking, such as turning on the air conditioner in advance, adjusting the air conditioner temperature, or turning off devices that are not powered off.

[0047] Existing vehicle-to-home (V2X) solutions mostly revolve around appliance brand integration, protocol interoperability, and control forwarding. Their operation typically involves the vehicle generating a control request, which is then relayed via an intermediate cloud platform or gateway to the corresponding brand's open platform. The brand's open platform then issues commands to the appliances. While this approach can achieve basic control with a single brand or a small number of brands, it reveals significant shortcomings in multi-brand scenarios. Firstly, different brand open platforms have significantly different requirements regarding the meaning, naming conventions, and formats of control parameters. Even for seemingly simple actions like temperature settings, fan speed adjustments, or mode switching, different platforms may use different fields, parameter ranges, or even different state semantics. This makes it difficult for the cloud to directly generate valid commands that can be recognized by the target brand's open platform after receiving a unified control intent from the vehicle. On the other hand, existing solutions often focus more on protocol layer integration, while neglecting to handle the logical relationship between the current state of the device and control parameters. For example, when a user issues a control command, if the target appliance is currently in a certain restricted working state, the vehicle side and the intermediate platform usually do not make a judgment in advance, but instead forward it directly to the device. In the end, the system can only rely on the brand's open platform or the device to return a failure message after execution, which will result in a significant response delay.

[0048] The inconsistent interface entry points, authentication methods, and message encapsulation rules of multi-brand open platforms necessitate separate development and adaptation for each brand during vehicle maintenance. Adding a new brand or changing brand interfaces requires repeated logic adjustments, increasing development costs and reducing system stability. Therefore, while existing technologies can achieve remote control of vehicles and home appliances to some extent, they lack sufficient support for state consistency, command compatibility, and feedback timeliness in cross-brand control, failing to meet the practical needs of unified control and efficient response in complex home environments.

[0049] In view of this, this application provides a vehicle-home interconnection method applied to a cloud server. By leveraging the vehicle cloud's adaptation processing of various brand home appliance object models, a unified control interface is created for the vehicle, enabling the vehicle to output control commands regardless of brand differences in home appliances. Meanwhile, the vehicle cloud checks whether there is mutual exclusion between the current device status and the control parameters in the control command. If no mutual exclusion is confirmed, the command is then issued according to the format requirements of the brand's open platform.

[0050] Example 1

[0051] Figure 1 This is a schematic diagram of the vehicle-home interconnection method provided in this application, such as... Figure 1 As shown, it includes the following steps:

[0052] S101: Obtain control commands sent by the vehicle-side terminal for controlling home appliances. The control commands include home appliance association identifiers and control parameters.

[0053] In this embodiment, the cloud server serves as the execution entity of the method, handling control request access, semantic parsing, brand adaptation, and instruction forwarding in the vehicle-home interconnection scenario. The cloud server can be deployed as an application service node in a vehicle-to-everything (V2X) business cloud, or as a middleware service cluster for multi-brand home appliance platforms, establishing communication connections with vehicle-side terminals through authentication gateways, message buses, or interface services. Vehicle-side terminals can be the vehicle's infotainment system or other terminal devices, such as mobile phones.

[0054] Control commands are appliance control requests sent by the vehicle to the cloud server. They carry the user's intention to operate the appliances and include at least the appliance's associated identifier and control parameters. The appliance associated identifier identifies the appliance to be controlled and its brand's open platform. In specific implementations, it can be a unique identifier for the appliance, a vehicle identifier, a user identifier, a logical device number within the home, a combination of brand number and device number, or other identifying information that can uniquely locate the target appliance and its brand origin.

[0055] Control parameters are used to characterize the control actions performed on home appliances and their specific values, such as turning on and off the air conditioner, setting the temperature to 26 degrees Celsius, switching the cooling mode, adjusting the fan speed, or controlling the switching on and off of lights, brightness percentage, color temperature parameters, etc.

[0056] Control commands sent by the vehicle-side terminal to control home appliances can be generated by the in-vehicle voice assistant, the central control screen touch interface, the quick control interface triggered by the steering wheel buttons, or a mobile terminal application bound to the vehicle account, and then transmitted to the cloud server via the vehicle communication module and the vehicle-cloud communication link.

[0057] In scenarios where multiple households and vehicles share the same cloud service, the cloud server can combine the user account bound to the vehicle and the home space information to verify the attribution of home appliance association identifiers, thus preventing control requests from being mistakenly sent to devices in the wrong home. By uniformly receiving and parsing control commands on the cloud side, the vehicle side does not need to directly adapt to the differentiated interfaces of different brands of home appliances. It can first express the control intent with control commands in a consistent format, establishing a unified data foundation for subsequent status acquisition, mutual exclusion judgment, and command generation.

[0058] S102: Obtain the current device status of the home appliance from the open platform of the brand to which the home appliance association identifier belongs.

[0059] The brand open platform is a platform provided by the home appliance brand to receive control requests from the cloud and control the home appliance to perform operations. It also returns device status information to the cloud. The current device status is real-time status information provided by the brand open platform, indicating the current operating status of the home appliance.

[0060] In practice, after the cloud server completes the parsing of the control command, it can query the target home appliance's brand information, platform access address, authentication credential type, and status query interface template in the device mapping table, brand routing table, or home device registration relationship table based on the home appliance association identifier, and then initiate a status acquisition request to the corresponding brand open platform.

[0061] To adapt to the requirements of different brand open platforms, the cloud server can pre-configure access tokens, interface keys, signature algorithms, timestamp generation rules, and request header field templates for each brand, and automatically select the corresponding brand's platform access strategy based on the home appliance association identifier during the query.

[0062] The current device status returned by the brand open platform can include device online status, on / off status, operating mode, temperature setting, fan speed, child lock status, sleep mode, fault code, power status, or other fields that can characterize the current working status of the device.

[0063] Because different brands have different naming conventions and semantic definitions for status fields, the cloud server can perform a status standardization process after receiving the status response. This will map the original status of the brand to a unified status model within the platform. For example, the values ​​"cool", "refrigeration", and "mode=1" that represent the air conditioner's operating mode in different brands can be uniformly mapped to the internal enumeration "refrigeration mode", which will facilitate subsequent rule judgment.

[0064] Furthermore, if the brand's open platform supports device status push notifications, the cloud server can continuously receive device status change events through a subscription method, and directly call the most recent valid status as the current device status when a control command is received.

[0065] The cloud server can understand the current operating status of the device before issuing control actions, avoiding blindly forwarding commands based solely on the vehicle's control intentions. This provides conditions for subsequent identification of control conflicts, improvement of execution effectiveness, and reduction of invalid calls.

[0066] S103: Determine whether the current device status and control parameters are mutually exclusive according to the preset mutual exclusion logic rules.

[0067] The pre-defined mutual exclusion logic rules are a set of rules used to determine whether the current device state and control parameters conflict. These rules are used to identify unexecutable control requests before control commands are officially generated and issued. The current device state reflects the objective situation of the device's operation, while the control parameters reflect the control intent initiated by the vehicle. The cloud server matches and compares these two, and determines whether a relationship exists that is not allowed to be simultaneously true, based on the pre-defined mutual exclusion logic rules. When the two conflict, mutual exclusion is determined; when they meet the device control logic requirements, mutual exclusion is determined not to exist.

[0068] In practical implementation, the cloud server can maintain a rule engine internally, configuring multi-level rules based on appliance type, brand, and function dimensions. For example, for air conditioners, if the current device status indicates the device is off, but the control parameter is only "increase fan speed" without any power-on action, then the control parameter and the current status are mutually exclusive. If the current status indicates the device is in smart mode, but the control parameter requires adjusting the temperature to 20°C, then mutual exclusivity can also be determined based on the rules for smart mode. For lighting devices, if the current status indicates the device does not support color temperature adjustment, but the control parameter includes a color temperature value, then mutual exclusivity can be determined.

[0069] The aforementioned mutual exclusion logic rules are pre-configured on the cloud server. These rules can be divided into two layers: general logic rules and brand-specific logic rules. General logic rules are used to handle control constraints that are generally applicable to similar types of home appliances, while brand-specific logic rules are used to handle the special requirements of specific brands in terms of parameter range, mode switching, and device limitations.

[0070] When making judgments, the cloud server first identifies the appliance type and brand based on the appliance association identifier, and then selects the corresponding rule set. It uses the standardized current device status and standardized control parameters as input to execute rule matching, outputting a mutual exclusion judgment result and the specific reason for the conflict. For parameter-based controls, the cloud server can also perform range checks, such as whether the temperature parameter is within the range supported by the brand's open platform, or whether the fan speed exceeds the upper limit supported by the device.

[0071] For example, the control command indicates: "Turn on the air conditioner to smart mode and set the temperature to 20°C." However, if a certain air conditioner brand cannot adjust the temperature when the mode is set to smart mode, the command will be sent to the brand and a command mutual exclusion will be indicated. However, the overall process is relatively long, and the user waits for a long time. After adaptation, the user's command can be immediately indicated on the vehicle side as a command mutual exclusion and cannot be sent, which significantly reduces the user's waiting time in the vehicle-home interconnection scenario.

[0072] By placing mutual exclusion checks in the cloud-based control process, invalid operations and state conflicts can be identified in advance before execution on the brand open platform. This avoids the lag problem in existing technologies where incompatible instructions are directly forwarded to the device and then return a failure. As a result, the vehicle side receives control result feedback earlier, improving system response efficiency and reducing the number of invalid calls to the brand open platform.

[0073] S104: If there is no mutual exclusion, then based on the format requirements of the brand open platform, generate and issue instructions according to the appliance association identifier and control parameters.

[0074] As the receiving end of cloud-based command transmission, brand open platforms typically have different requirements for request fields, parameter expressions, authentication information, message structure, and encoding methods. Therefore, after confirming that there are no mutual exclusions, the cloud server does not directly forward the original control commands from the vehicle side. Instead, based on the format requirements of the brand open platform, it performs adaptation and conversion according to the appliance association identifier and control parameters to generate commands that can be recognized and processed by the target brand open platform.

[0075] In practice, the cloud server first determines the target brand's open platform and the target device's identifier based on the appliance association identifier. Then, it reads the corresponding interface path, request method, field naming rules, parameter mapping table, enumeration value conversion relationship, signature rules, and data encapsulation format from the brand adaptation configuration. It then converts the platform's internally unified semantic control parameters into the parameter expression method required by the brand's open platform. For example, "cooling mode" in the internal control semantics can be converted into the numerical code "1" in a brand's interface, and "26 degrees Celsius" can be converted into the field "targetTemp=26," and organized according to its interface specifications into JSON messages, form parameters, XML messages, or binary data bodies.

[0076] The cloud server can also add necessary context fields to the issued instructions, such as request serial number, call timestamp, user authorization token and signature digest, to ensure that the brand open platform can correctly accept, verify and process the instructions.

[0077] In some embodiments, the cloud server can also perform multi-field splitting and encapsulation, for example, splitting "turn on the air conditioner and set the cooling temperature to 26 degrees Celsius with high fan speed" into a power-on field, a mode field, a temperature field, and a fan speed field, and then packaging them according to the order and structure required by the brand.

[0078] By generating unified command formats conforming to the brand's open platform requirements on the cloud side, the vehicle side does not need to directly handle the differences in multi-brand interfaces, thus decoupling cross-brand control semantics from brand-specific protocols. This approach significantly improves compatibility under multi-brand access conditions, reduces modifications to vehicle-side logic when adding a new brand, and mitigates the risk of command failures due to inconsistent fields or mismatched parameter formats through a unified adaptation layer. The cloud server can establish separate format conversion rule bases for different brand open platforms and manage interface changes through a version number mechanism.

[0079] S105: Send the command to the brand open platform. The command is used to instruct the brand open platform to control the home appliances.

[0080] In this embodiment, after generating the command, the cloud server sends the command to the corresponding brand open platform, enabling the brand open platform to perform control operations on the home appliance according to the command. Upon receiving the command, the brand open platform can further convert it into control information suitable for its internal processing and send the control command to the target home appliance through its own IoT channel, allowing the home appliance to perform the corresponding action.

[0081] There are no restrictions on the communication methods between the cloud server and the brand's open platform.

[0082] When the brand open platform returns a successful control response, the cloud server can further record the request log, sending time, return code, and target platform information to facilitate subsequent tracking and operation and maintenance analysis. When the brand open platform returns a failure result, the cloud server can determine whether it is authentication failure, device offline, parameter error, or platform failure based on the failure code, and generate a structured result to be fed back to the vehicle side.

[0083] This application provides a method for vehicle-home interconnection, comprising: acquiring a control command sent by a vehicle for controlling home appliances, the control command including an appliance association identifier and control parameters; acquiring the current device status of the home appliance from the open platform of the brand to which the appliance association identifier belongs; determining whether the current device status and control parameters are mutually exclusive according to preset mutual exclusion logic rules; if no mutual exclusion exists, generating a command to be issued based on the format requirements of the brand open platform, according to the appliance association identifier and control parameters; and sending the command to the brand open platform, the command being used to instruct the brand open platform to control the home appliance. By incorporating control request access, device status confirmation, status and parameter conflict verification, command formatting generation for the brand open platform, and final control issuance into a unified processing flow on the cloud server side, the vehicle side only needs to express a unified control intent without having to adapt to the differences in interfaces of various brands, thereby improving control compatibility and platform scalability in vehicle-home interconnection scenarios with mixed access of multiple brands of home appliances.

[0084] By introducing current device status acquisition and mutual exclusion logic judgment before controlling home appliances, invalid operations and conflicting requests can be identified and processed in advance in the cloud. This avoids the direct forwarding of requests that do not meet the execution conditions to the brand open platform and then passively returning failure. As a result, the feedback path can be shortened, the response time can be improved, and the system resource consumption caused by invalid calls can be reduced.

[0085] Based on the aforementioned embodiments, if mutual exclusion is determined during mutual exclusion verification, a response message to indicate instruction conflict is generated and sent to the vehicle.

[0086] For example, the target appliance is in an operating mode where parameter modification is prohibited, but the control command modifies the parameters; or the control parameters exceed the range of values ​​allowed in the current state.

[0087] The response message can also carry an explanation of the conflict reason, so that the vehicle can directly output a prompt to the user after receiving the message. If the vehicle is connected to an in-vehicle voice assistant or central control display interface, it can generate text prompts, voice prompts, or graphic prompts based on the response message to notify the user that the current control request cannot be executed temporarily.

[0088] When the cloud server determines that there is a conflict between the current device status and the control parameters, it no longer sends control commands to the brand's open platform. Instead, it directly generates and sends back a response message, allowing the vehicle to promptly understand the reason for the control failure. Because the conflict information is identified and fed back in the cloud, invalid commands are prevented from being transmitted to downstream platforms, thereby reducing waiting time and retry overhead in the control chain. Adopting this approach, the vehicle receives more timely conflict alerts, and users can adjust control parameters or change control intentions accordingly, thus improving the usability, interaction efficiency, and system stability of vehicle-to-home connectivity control.

[0089] In some embodiments, control commands sent by the vehicle-side terminal for different appliance brands use the same format. This consistent format ensures that the control commands for different appliance brands are structurally consistent, facilitating unified generation of control commands on the vehicle side and unified parsing by the cloud server.

[0090] The consistent format means that control commands maintain consistency in message structure, field arrangement, parameter placement, and data organization. Control commands can be generated from a unified command template, where appliance association identifiers and control parameters correspond to fixed fields and are filled in sequentially according to a preset order. Control parameters use a fixed template. Vehicles do not need to configure separate message splicing rules for each brand. When adding a new brand, only the object model in the cloud server needs to be configured. After receiving a vehicle request, the cloud server can directly extract the content of each field according to the same parsing logic and complete the command parsing according to the same generation logic.

[0091] Based on any of the foregoing embodiments, if the brand open platform is unable to execute the issued instruction, it will return an error code; the cloud server receives the error code sent by the brand development platform; according to the preset mapping relationship between each brand error code and the unified error code, the error code is converted into a vehicle-side response error code; and the response error code is sent to the vehicle-side terminal.

[0092] Error codes are used to characterize abnormal results or failure reasons after the brand development platform executes control over home appliances. These error codes are generated by the brand development platform according to its own protocol specifications. Upon receiving the error code, the cloud server performs conversion processing based on a pre-defined mapping relationship between error codes for each brand and a unified error code. This ensures that even when the brand platform returns different encoding formats, it can still be converted into a unified response error code recognizable by the vehicle, eliminating the need for the vehicle to separately parse the error return content for each brand.

[0093] The differentiated error information returned by the brand development platform can be uniformly converted in the cloud and fed back to the vehicle, thereby enabling the vehicle to perceive abnormal appliance operation in a standardized way and avoid inconsistencies in error display or parsing failures caused by brand differences.

[0094] Building upon any of the foregoing embodiments, furthermore, different brands have different mutual exclusion logic rules. Therefore, before determining whether the current device status and control parameters are mutually exclusive, it is also necessary to determine the mutual exclusion logic rules of the brand to which the appliance association identifier belongs, based on the appliance association identifier. By determining the mutual exclusion logic rules corresponding to the brand before mutual exclusion judgment, the cloud server can establish a judgment basis at the brand level, making the conflict identification between the current device status and control parameters more accurate and avoiding misjudgments or omissions caused by different brand control constraints.

[0095] In one specific embodiment, the appliance-associated identifier is a vehicle identifier. The method further includes: determining the appliance identifier corresponding to the vehicle identifier based on a pre-set mapping relationship between vehicle identifiers and appliance identifiers; and determining the address of the brand open platform based on the appliance identifier.

[0096] In this embodiment, the user pre-binds a mapping relationship between home appliance and vehicle identifiers. After recognizing the vehicle identifier, the home appliance identifier can be determined. Specifically, upon receiving a control request containing the vehicle identifier, the cloud server accesses a pre-established mapping table and retrieves the corresponding home appliance identifier using the vehicle identifier. This mapping table can be stored in the form of key-value pairs, database records, or cache indexes, facilitating the establishment of a stable correspondence between vehicle and home appliance identifiers, thus enabling different vehicles to be accurately associated with their respective bound home appliance resources. After obtaining the home appliance identifier, the cloud server further queries the corresponding brand open platform address based on the home appliance identifier. This address can be recorded as a Uniform Resource Locator (URL), interface domain name, or service gateway entry point. Based on this, the cloud server can locate the target brand open platform and send subsequent status acquisition requests, control commands, or result feedback requests to this address, enabling access and control of the target home appliance. If the brand open platform is deployed in a partitioned or multi-regional manner, the home appliance identifier can also be associated with a platform instance identifier to further determine the available access address.

[0097] Through the above processing, the vehicle only needs to provide the vehicle identifier, and the cloud can complete the conversion from the vehicle identifier to the appliance identifier, further locating the communication entry point of the brand's open platform. This method reduces the vehicle's direct perception of brand interface differences.

[0098] Figure 2 The architecture diagram of the vehicle-home interconnection adapter provided in this application is shown in reference to... Figure 2 The vehicle connects to the cloud service through its own authentication gateway, and then accesses the vehicle-home interconnection adapter for business data interaction. Simultaneously, the smart home appliance platform transmits data such as home appliance data and models to the vehicle-cloud adapter through the unified open platform gateway of the vehicle-cloud. This application specifically includes the following modules at the service application layer:

[0099] 1. The vehicle-home interconnection smart home appliance configuration management module includes the following functions:

[0100] 1) Brand Category Model Configuration: Establish cooperative mechanisms with various home appliance brands to obtain their third-party device object model documents. Simultaneously, regularly collect information on newly emerging home appliance products in the market and product updates from the official websites of various home appliance brands, and update the category object models in a timely manner. Based on the collected object model documents, classify and organize home appliances from different brands, and build a unified, cloud-specific category object model for each category. During the construction process, abstract and integrate the common functions and characteristics of home appliances from various brands, while retaining the unique functional identifiers of each brand. For example, for the smart air conditioner category, the unified object model includes common attributes and operations such as temperature adjustment and fan speed adjustment, while setting specific identifiers for functions unique to different brands (such as a brand's health mode).

[0101] 2) Error Code Configuration: Collect error code documents from each connected third-party brand to understand in detail the error codes returned by each brand's home appliances under different fault conditions and their meanings. For example, a certain brand of smart refrigerator returns error code "E01" when the refrigeration system fails, indicating a compressor failure; another brand may use a different error code to represent a similar fault. Based on the collected error code documents, develop a unified vehicle-side response error code. Map and match the different error codes of each brand with the unified error code to ensure that when the vehicle receives fault information from home appliances of different brands, it can present it to the user in a unified and standardized error code format.

[0102] 3) Mutual Exclusion Command Configuration: Obtain mutual exclusion command documents from the third-party brands involved, clarifying the mutually exclusive command pairs and their application scenarios in each brand's home appliances. For example, a certain brand of air conditioner may not allow temperature adjustment in smart mode or ventilation mode. Based on the obtained mutual exclusion command documents, configure the mutual exclusion commands uniformly in the management center. As home appliance brands launch new features or optimize existing functions, the mutual exclusion command relationships may change. Therefore, it is necessary to obtain updated mutual exclusion command information in a timely manner and adjust the mutual exclusion command configuration in the management center accordingly to ensure that the system can always accurately identify and handle mutual exclusion command situations.

[0103] 4) Vehicle configuration compatibility: Clarify the vehicle's functional configuration and features, determine whether vehicle-to-home connectivity is required, and whether only certain brands offer vehicle-to-home connectivity.

[0104] 2. Standardized vehicle-side interface module:

[0105] The standardized interface design module designed and built a standardized communication interface. This interface adopts a common protocol and a unified data format, establishing a stable and efficient bridge for communication between the vehicle and the vehicle-cloud. Regarding command transmission, the encoding method, field composition, and command type identifier are clearly defined. For example, all control command requests are encapsulated in JSON format, which must include "reqId" (request ID), "device_type" (device type), "command" (command content), and "parameters" (parameter list). Responses must include fixed fields such as "respId" (response ID). When the vehicle sends appliance control commands, it only needs to assemble them according to this standardized format, without needing to concern itself with the complex and diverse communication details of different appliance brands. When the vehicle recognizes the user's intention to control the appliance, it transmits the user's command to the command parsing module in the adapter for command parsing through the standardized interface.

[0106] 3. Command Parsing Module: Based on the functional characteristics and control command logic of different home appliances, a detailed command parsing rule base is constructed. The rule base is stored in a hierarchical structure for quick querying and expansion. For each type of home appliance, the syntax structure of the command is defined, including the command format, parameter types, and order. A detailed semantic explanation is defined for each command, clarifying its specific function and expected effect.

[0107] Figure 3 This application provides a schematic diagram of the command control flow for vehicle-home interconnection, such as... Figure 3 As shown, when a command is received from the vehicle, the command parsing module first extracts the command device type. Then, based on the device type, it queries the parsing rule base for the corresponding command syntax and parsing rules. The command is then segmented and parameters are extracted according to the syntax rules, and finally, the parameters are validated and converted according to semantic interpretation and parameter verification rules.

[0108] For example, for the instruction "lighting:setBrightness:80", the device type is first determined to be a smart light fixture. Then, the operation "setBrightness" and the parameter "80" are extracted according to the rules. After verifying that "80" conforms to the brightness value range, it is converted into an internal representation. If the instruction format does not conform to the syntax rules or the parameter validation fails, detailed error information is returned to the vehicle, such as "Parameter value error, brightness value must be between 0 and 100". After parsing the instruction, semantic validation is performed based on the current state and functional logic of the home appliance. For example, for a smart TV, if it is currently off, the "adjust volume" instruction is invalid. After the semantic validation passes, the parsed instruction is converted into the adapter's internal unified format, including information such as device type, operation type, parameter list, and instruction source. If the semantic validation fails, an error message is returned to the vehicle explaining the reason for the invalid instruction, such as "The device is currently off, this operation cannot be executed".

[0109] 4. Mutual Exclusion Command Judgment Module: Upon system startup, the mutual exclusion command judgment module loads all configured mutual exclusion command rules from the management center. These rules are stored in a hash table structure in memory, using device type and command pairs as keys to quickly locate and match mutual exclusion commands. This allows for rapid lookup of relevant mutual exclusion command rules upon receiving a command, improving judgment efficiency.

[0110] like Figure 3As shown, when a command is received from the command parsing module, the mutual exclusion command determination module first determines the corresponding hash table based on the device type of the command. Then, it matches the received command with the mutual exclusion command pairs in the hash table. If a matching mutual exclusion command pair is found, it checks whether the mutual exclusion condition is met based on the current device status and the status of executed commands. For example, for the air conditioner's "targetTemperature: 25" command, it checks whether the current reported air conditioner status is "operationMode: auto". If it exists, the mutual exclusion condition is met. If it is determined to be a mutual exclusion command, the command is immediately intercepted, and a response message is quickly sent to the vehicle-side user, informing the user of the command conflict and inability to execute via a pop-up window or voice announcement. If it is determined not to be a mutual exclusion command, the command is directly passed to the distribution module for further processing.

[0111] 5. Command Distribution Module: Collect the interface documentation provided by each brand's open platform, and gain a detailed understanding of each brand's interface functions, request formats, authentication methods, response data structures, and other information. Develop corresponding interface integration modules for each brand to achieve communication and interaction with the brand's open platform.

[0112] like Figure 3 As shown, upon receiving an instruction from the mutual exclusion instruction judgment module, the instruction distribution module first determines the interface integration module to be called based on the brand information of the instruction. If no corresponding interface integration module is found, the user is directly prompted that the instruction delivery failed to avoid excessive waiting. If a corresponding interface integration module is found, the instruction in the adapter's internal format is encapsulated according to the format required by the brand open platform. For example, if the brand open platform requires the request body to be in JSON format, then the internal instruction "{targetTemperature: '25',}" is encapsulated as "[{"argCode":" targetTemperature","argValue":"'25'","argName":"temperature","argIcon":"","sort":1}]", and after adding the necessary authentication information and request headers, the interface integration module is called to send the encapsulated instruction to the brand open platform.

[0113] 6. Home Appliance Status Reporting Module: Based on the device status synchronization communication method provided by the third-party platform, a stable connection is established with each home appliance to receive real-time status data reports. Corresponding configurations and adaptations are performed for the communication characteristics of different brands of home appliances. Then, the format differences of status data from the same type of home appliance across different brands are analyzed, and detailed format conversion rules are formulated. The data is converted according to the pre-defined format conversion rules. Data processing algorithms and tools are used to parse the raw data, extract key information, and reassemble it according to a unified format. Finally, the standardized home appliance status data is distributed to the vehicle through a standardized vehicle-side interface module.

[0114] Figure 4 This is a schematic diagram illustrating the status reporting process for smart home appliances connected to the vehicle, as provided in this application. Figure 4 As shown, after the command is issued to each home appliance, the appliance reports its status and current condition to the home appliance platform based on the command control. After being certified by the vehicle cloud open platform, the home appliance platform synchronously reports its current device status according to the agreed communication method. Upon receiving the status data reported by the home appliances, the cloud performs format conversion and quality checks on the converted data. The data integrity is checked to ensure all necessary fields exist; the accuracy is checked, such as whether numerical fields are within a reasonable range and whether enumerated fields are valid values. The processed standardized format home appliance status data is then sent to the standardized vehicle-side interface module, and the relevant device data is simultaneously stored in the database for later backtracking and troubleshooting.

[0115] Through the detailed implementation methods described above, the vehicle-home interconnection adapter of this application can achieve efficient, stable, and convenient interconnection and unified control between vehicles and various brands of smart home appliances.

[0116] This application also provides a vehicle-home interconnection device, the device comprising:

[0117] The acquisition module is used to acquire control commands sent by the vehicle-side terminal for controlling home appliances. The control commands include home appliance association identifiers and control parameters.

[0118] The status query module is used to obtain the current device status of home appliances from the open platform of the brand to which the home appliance association identifier belongs;

[0119] The mutual exclusion verification module is used to determine whether the current device status and control parameters are mutually exclusive according to preset mutual exclusion logic rules;

[0120] The format conversion module is used to generate and issue instructions based on the brand open platform's format requirements, appliance association identifiers, and control parameters, if no mutual exclusion exists.

[0121] The sending module is used to send instructions to the brand's open platform, which in turn instructs the brand's open platform to control home appliances.

[0122] Furthermore, the device also includes a mutual exclusion feedback module for:

[0123] If mutual exclusion exists, a response message is generated to indicate a command conflict;

[0124] The response message is sent to the vehicle-side terminal.

[0125] Furthermore, control commands from different home appliance brands use the same format.

[0126] Furthermore, the status query module is also used to: receive error codes sent by the brand open platform;

[0127] The format conversion module is also used to convert error codes into vehicle-side response error codes based on the preset mapping relationship between error codes of various brands and unified error codes;

[0128] The sending module is also used to send response error codes to the vehicle-side terminal.

[0129] Furthermore, the mutual exclusion verification module is also used for:

[0130] Based on the appliance association identifiers, determine the mutual exclusion logic rules of the brands to which the appliance association identifiers belong.

[0131] The apparatus provided in this embodiment can execute the methods provided in the above method embodiments. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0132] Figure 5 This is a schematic diagram of the server structure provided in this application. Figure 5 As shown, the server 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the server 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0133] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0134] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0135] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0136] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0137] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0138] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0139] This application also provides a vehicle, including a vehicle body and vehicle-side equipment, the vehicle-side equipment being used in conjunction with the process of generating control commands in the above method embodiments.

[0140] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0141] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0142] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0143] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0144] The units described as separate components may or may not be physically separate. The components shown as units 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.

[0145] In addition, the functional units in the various embodiments of the present invention 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.

[0146] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part 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 methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0147] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0148] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for vehicle-home interconnection, characterized in that, Applied to a cloud server, the method includes: The system acquires control commands sent by the vehicle-side terminal for controlling home appliances, the control commands including home appliance association identifiers and control parameters; Obtain the current device status of the home appliance from the open platform of the brand to which the home appliance association identifier belongs; Based on preset mutual exclusion logic rules, determine whether the current device state and the control parameters are mutually exclusive; If no mutual exclusion exists, then based on the format requirements of the brand open platform, instructions are generated and issued according to the home appliance association identifier and the control parameters; The instruction is sent to the brand open platform, and the instruction is used to instruct the brand open platform to control the home appliances.

2. The method according to claim 1, characterized in that, The method further includes: If mutual exclusion exists, a response message is generated to indicate a command conflict; The response message is sent to the vehicle-side terminal.

3. The method according to claim 1, characterized in that, Different home appliance brands use the same format for control commands.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: Receive the error code sent by the brand's open platform; Based on the preset mapping relationship between error codes of each brand and unified error codes, the error codes are converted into response error codes at the vehicle end; The response error code is sent to the vehicle-side terminal.

5. The method according to any one of claims 1-3, characterized in that, Before determining whether the current device state and the control parameters are mutually exclusive, the method further includes: Based on the appliance association identifier, determine the mutual exclusion logic rules of the brand to which the appliance association identifier belongs.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: (The appliance-associated identifier is a vehicle identifier.) Based on the pre-set mapping relationship between vehicle identifiers and home appliance identifiers, determine the home appliance identifier corresponding to the vehicle identifier; The address of the brand's open platform is determined based on the appliance's identifier.

7. A vehicle-home interconnection device, characterized in that, The device includes: The acquisition module is used to acquire control commands sent by the vehicle-side terminal for controlling home appliances. The control commands include home appliance association identifiers and control parameters. The status query module is used to obtain the current device status of the home appliance from the open platform of the brand to which the home appliance association identifier belongs; The mutual exclusion verification module is used to determine whether the current device state and the control parameters are mutually exclusive according to preset mutual exclusion logic rules. The format conversion module is used to generate and issue instructions based on the format requirements of the brand open platform, the appliance association identifier, and the control parameters, if no mutual exclusion exists. The sending module is used to send the issued instruction to the brand open platform, and the issued instruction is used to instruct the brand open platform to control the home appliance.

8. A server, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images