Intelligent device control method and apparatus

Abstract

The application discloses an intelligent device control method and device, and is applied to the fields of communication, intelligent automobile and intelligent Internet of Things. The intelligent device control method comprises the following steps: in the case that an input of a user selecting a first scene service is received, a device control strategy corresponding to the first scene service is acquired; the device control strategy comprises at least two target intelligent devices and a control scheme corresponding to the at least two target intelligent devices; based on the device control strategy, communication connections with the at least two target intelligent devices are established respectively; device operation instructions are sent to each target intelligent device according to the control scheme; and the device operation instructions are used for instructing the target intelligent device to perform corresponding operations. The method can simplify the operation process of multi-intelligent device cooperative control, improve the control efficiency of the intelligent device, and effectively solve the problems of complicated multi-intelligent device cooperative control process and low control efficiency.

Description

Technical Field

[0001] This application belongs to the fields of communication, intelligent vehicles, and intelligent Internet of Things, and particularly relates to a method and apparatus for controlling intelligent devices. Background Technology

[0002] With the rapid development and widespread application of IoT technology, various smart devices are being widely used in fields such as industrial control, environmental monitoring, smart homes, and vehicle systems.

[0003] In related technologies, when users need to coordinate multiple smart devices to complete a specific service through a control device, they first need to manually configure the network connection of each smart device involved in the coordination. During service execution, users also need to manually select and specify the controlled devices required for this service from the multiple connected smart devices, and then send control commands one by one to achieve collaborative work between multiple controlled devices. The operation process is cumbersome and reduces the control efficiency of smart devices. Summary of the Invention

[0004] This application provides a method, apparatus, device, computer-readable storage medium, and computer program product for controlling intelligent devices, which can solve the problem of low efficiency in the coordinated control of multiple intelligent devices.

[0005] In a first aspect, embodiments of this application provide a smart device control method applied to an electronic device. The smart device control method includes: upon receiving input from a user selecting a first scenario service, obtaining a device control strategy corresponding to the first scenario service; the device control strategy includes at least two target smart devices and a control scheme corresponding to the at least two target smart devices; based on the device control strategy, establishing communication connections with the at least two target smart devices respectively; and sending a device operation instruction to each target smart device according to the control scheme; the device operation instruction is used to instruct the target smart device to perform a corresponding operation.

[0006] Secondly, embodiments of this application provide an intelligent device control apparatus applied to an electronic device. The intelligent device control apparatus includes: an acquisition module, configured to acquire a device control strategy corresponding to the first scenario service upon receiving input from a user selecting the first scenario service; the device control strategy includes at least two target intelligent devices and control schemes corresponding to the at least two target intelligent devices; a connection module, configured to establish communication connections with the at least two target intelligent devices based on the device control strategy; and a sending module, configured to send device operation instructions to each target intelligent device according to the control scheme; the device operation instructions are used to instruct the target intelligent device to perform corresponding operations.

[0007] Thirdly, embodiments of this application provide an electronic device, the device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the intelligent device control method as described in any of the first aspects.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the intelligent device control method as described in any of the first aspects.

[0009] Fifthly, embodiments of this application provide a computer program product, which includes a computer program or instructions that, when executed by a processor, implement the intelligent device control method as described in any of the first aspects.

[0010] The intelligent device control method, apparatus, device, computer-readable storage medium, and computer program product of this application embodiment enable the electronic device to obtain the corresponding device control strategy when it receives input from the user to select a first scenario service. Based on the device control strategy, it can automatically establish communication connections with multiple target intelligent devices and send device operation instructions to the target intelligent devices according to the control scheme. This eliminates the need for the user to manually configure connections, filter intelligent devices, and send device operation instructions one by one. It simplifies the operation process of multi-intelligent device collaborative control, improves the control efficiency of intelligent devices, and effectively solves the problems of cumbersome process and low control efficiency in existing multi-intelligent device collaborative control. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating some embodiments of the intelligent device control method provided in this application is shown; Figure 2 The diagram illustrates a specific implementation of step 130 provided in some embodiments of this application; Figure 3 A flowchart illustrating the device status query instruction generation method of the intelligent device control method provided in some embodiments of this application is shown. Figure 4 The diagram illustrates a frame parsing processing method for a smart device control method provided in some embodiments of this application. Figure 5 The diagram illustrates a specific implementation of step 180 provided in some embodiments of this application; Figure 6 A flowchart illustrating a specific implementation of step 190 provided in some embodiments of this application is shown; Figure 7 The present application provides a schematic diagram of the structure of a smart device control apparatus according to some embodiments; Figure 8 The diagram shows a schematic representation of the structure of an electronic device provided in some embodiments of this application. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are intended only to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

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

[0015] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0016] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0017] To address the problems in the aforementioned related technologies, embodiments of this application provide a smart device control method, apparatus, device, computer-readable storage medium, and computer program product.

[0018] The following is in conjunction with the appendix Figure 1 To be continued Figure 5 The intelligent device control method provided in this application will be described in detail through specific embodiments and application scenarios.

[0019] The intelligent device control method provided in this application is applied to an electronic device, which refers to an intelligent device with computing, storage, and communication capabilities, capable of receiving user input, processing data, and sending control commands to external intelligent devices. The electronic device can be an intelligent device with an operating system installed. Specifically, the electronic device can be an Android device, i.e., a device with the Android operating system installed. Specifically, the electronic device can be a general-purpose computing device, including but not limited to: desktop computers, laptop computers, and server computers; it can also be a mobile device, including but not limited to: smartphones and tablet computers; and it can also be a smart home control device, including but not limited to: smart speakers, smart central control screens, and smart gateways.

[0020] Figure 1 A flowchart illustrating some embodiments of the intelligent device control method provided in this application is shown. Figure 1 As shown, the intelligent device control method may include steps 110 to 130.

[0021] Step 110: Upon receiving input from the user selecting a first scenario service, obtain the device control strategy corresponding to the first scenario service; the device control strategy includes at least two target smart devices and a control scheme corresponding to the at least two target smart devices; Step 120: Based on the device control strategy, establish communication connections with the at least two target smart devices respectively; Step 130: According to the control scheme, send a device operation instruction to each target smart device; the device operation instruction is used to instruct the target smart device to perform the corresponding operation.

[0022] Therefore, when the electronic device receives the user's input of selecting the first scenario service, it can obtain the corresponding device control strategy, and then automatically establish communication connections with multiple target intelligent devices based on the device control strategy. It can also send device operation instructions to the target intelligent devices according to the control scheme. This eliminates the need for the user to manually configure connections, filter intelligent devices, and send device operation instructions one by one. It simplifies the operation process of multi-intelligent device collaborative control, improves the control efficiency of intelligent devices, and effectively solves the problems of cumbersome multi-intelligent device collaborative control process and low control efficiency.

[0023] The steps described above are explained in detail below.

[0024] First, regarding step 110, the first scenario service involved in this application embodiment refers to a service that requires multiple smart devices to work together to complete a specific function, which is preset or selected by the user according to actual service needs. For example, in the field of vehicle systems, there is the "long-distance driving comfort mode", "child safety mode" and "parking rest mode"; in the field of smart homes, there is the "home theater mode"; and in the field of industrial control, there is the "production line changeover mode".

[0025] In one embodiment, a device control policy may refer to a complete set of rules pre-configured by the user to guide the execution of a scenario service. This device control policy includes the specific target intelligent devices participating in the scenario service and the corresponding control scheme that each target intelligent device should execute. Target intelligent devices refer to all intelligent devices participating in the execution of the current first scenario service that need to be controlled by the electronic device. A control scheme refers to a series of operational instructions or parameter settings for a specific target intelligent device, which may include the state or actions that the target intelligent device should achieve in a specific scenario service.

[0026] In this step, if the electronic device is an in-vehicle device, the input can be a manual selection made by the user through the user interface of the in-vehicle device, such as the user clicking an icon associated with "Long-Distance Driving Comfort Mode" on the in-vehicle central control screen. The input can also be a voice command, such as the user saying "Activate Long-Distance Driving Comfort Mode" to the voice assistant of the in-vehicle device. Subsequently, after receiving this input, the in-vehicle device can retrieve the pre-configured device control policy corresponding to the first scenario service from the pre-configured policy database based on the identifier of the first scenario service.

[0027] In multi-device collaborative control scenarios, especially in intelligent cockpit device control within vehicle environments, operators often need to repeatedly execute a series of control actions according to a fixed time rhythm. For example, an operator might need to send a start command to test device A, wait 5 seconds, and then send a data acquisition command to test device B, repeating this cycle 3 times to complete multiple sets of tests. In related technologies, these timing control actions typically require manual execution one by one, which is not only cumbersome and inefficient but also prone to timing errors due to human error, affecting the normal operation of the equipment. Therefore, in some embodiments of this application, the electronic device can display a device control strategy configuration interface to the user. This interface includes a device selection area, an action configuration area, a timing parameter configuration area, and a loop parameter configuration area. Upon receiving user input in the device control strategy configuration interface, the electronic device generates a standardized device control strategy based on the user's input configuration information and stores it in the electronic device's strategy database.

[0028] The configuration information input by the user may include, but is not limited to: the user manually selecting one or more smart devices from the target device list to participate in this scenario service in the device selection area; the user selecting the corresponding control action for each selected target smart device in the action configuration area, and arranging the control actions in the execution order, including but not limited to turning on, turning off, raising, lowering, turning, adjusting brightness, adjusting volume, adjusting temperature, etc.; the user setting the waiting interval time after execution for each control action in the timing parameter configuration area, with the waiting interval time ranging from 0.1 seconds to 3600 seconds; and the user setting the number of rounds to be executed for the entire action sequence in the loop parameter configuration area, with the number of loops being a positive integer or an infinite loop.

[0029] In some embodiments of this application, the control execution engine also has a device grouping function. Users can group multiple smart devices into the same device group in the configuration interface. The control execution engine can simultaneously send the same control command to all smart devices within the same device group, achieving parallel control of multiple devices. For example, a user can group the vehicle's left front headlight, right front headlight, left rear headlight, and right rear headlight into a "vehicle lighting group." In the control strategy, only one "vehicle lighting group - turn on" action needs to be configured, and the control execution engine will simultaneously send turn-on commands to all four lights.

[0030] Furthermore, the in-vehicle electronic device also provides users with a device control policy management interface, where users can view, modify, delete, rename, and share stored device control policies. When a user modifies a device control policy, the in-vehicle electronic device automatically updates the corresponding persistent entity in the policy database.

[0031] In some embodiments of this application, the control execution engine also has a conflict detection function. When multiple device control strategies are executed simultaneously, the control execution engine will detect whether there are conflicting control commands for the same smart device. If a conflict is detected, the control command with higher priority will be executed according to a preset priority rule, and a conflict prompt will be issued to the user. In this way, it can effectively ensure that each smart device only accepts the control of one control scheme at any given time, avoiding abnormal behavior of smart devices caused by command conflicts. For example, when the "camping mode" control strategy is executing the vehicle inverter start action, if the user manually triggers the "vehicle shutdown" control strategy, the control execution engine will prioritize the vehicle inverter shutdown action in the "vehicle shutdown" control strategy and display a prompt message "Control conflict detected, vehicle shutdown strategy has been prioritized" on the central control screen.

[0032] Secondly, regarding step 120, after obtaining the device control policy, the electronic device will automatically establish communication connections with each target smart device based on the device control policy.

[0033] In some embodiments of this application, step 120 may specifically include: determining the priority order of at least two target smart devices based on the device priority information in the device control strategy; and establishing communication connections with at least two target smart devices in descending order of priority.

[0034] Device priority information refers to parameters pre-configured in the device control strategy that identify the importance and urgency of different target intelligent devices during the service execution process in in-vehicle scenarios. In in-vehicle systems, device priorities can be divided according to the degree of correlation between device functions and driving safety, with safety-related devices having the highest priority, followed by driver assistance-related devices, and comfort and entertainment-related devices having the lowest priority.

[0035] For example, device priorities can be divided into three levels. Smart devices directly related to driving safety are classified as Level 1 priorities, such as electronic stability control systems, automatic emergency braking systems, lane departure warning systems, airbag control units, and door locking systems. Smart devices related to driving experience and basic vehicle functions are classified as Level 2 priorities, such as power seats, power steering wheels, air conditioning systems, window control systems, and lighting control systems. Smart devices related to comfort and entertainment are classified as Level 3 priorities, such as in-car audio systems, in-car navigation systems, rear-seat entertainment systems, in-car refrigerators, and ambient lighting.

[0036] In this step, the priorities of at least two target smart devices can be sorted based on the device priority information in the device control strategy. Communication connections with at least two target smart devices are established sequentially in descending order of priority. Specifically, after successfully establishing a communication connection with the current high-priority target smart device, the process of establishing a communication connection with the next second-highest priority target smart device is initiated. If the communication connection with a target smart device fails to be established, that target smart device is skipped, and the process of establishing a communication connection with the next priority target smart device continues, and the connection failure information is recorded.

[0037] Furthermore, the in-vehicle electronic devices can adopt different connection failure handling strategies based on the device priority. Specifically, if a first-priority device fails to connect, the in-vehicle electronic device will immediately retry the connection 3 times. If it still fails, it will issue an emergency reminder of "safety device connection abnormality" to the driver via voice and the central control screen, and suspend the execution of the scenario service. If a second-priority device fails to connect, the in-vehicle electronic device will retry the connection 2 times. If it still fails, it will record the abnormal information and issue a prompt to the driver, and continue to execute other parts of the scenario service. If a third-priority device fails to connect, the in-vehicle electronic device will retry the connection 1 time. If it still fails, it will only record the abnormal information, without issuing a prompt to the driver, and continue to execute the scenario service.

[0038] Therefore, by determining the connection order based on device priority information and adopting a connection establishment process with step-by-step confirmation, it is ensured that smart devices that are important to users can establish communication connections in a priority and stable manner.

[0039] In some embodiments of this application, at least two target smart devices include at least one of the following: a first type of smart device and a second type of smart device; the first type of smart device is a device that supports the Bluetooth Low Energy protocol, such as various sensors and wearable devices. The second type of smart device is a device that supports a transmission control protocol, such as various execution control devices; this classification helps electronic devices select appropriate communication methods based on the characteristics of the smart devices.

[0040] Based on this, establishing communication connections with at least two target smart devices includes: establishing a communication connection with the target smart device via Bluetooth Low Energy protocol when the target smart device is a first type of smart device; and establishing a communication connection with the target smart device via Transmission Control Protocol when the target smart device is a second type of smart device.

[0041] Bluetooth Low Energy (BLE) is a wireless personal area network (PAN) technology designed to provide low-cost, low-power connectivity for short-range communication. Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol.

[0042] In this step, when an electronic device needs to establish a communication connection with at least two target smart devices, it first identifies the specific type of these target smart devices based on the device control policy. Specifically, it determines whether they are Type 1 smart devices supporting Bluetooth Low Energy or Type 2 smart devices supporting Transmission Control Protocol (TCP). Once the type of smart device is determined, the electronic device can intelligently select and enable the corresponding communication protocol stack. Specifically, the system through which the electronic device implements the communication connection can include a connection layer, a transport layer, a protocol layer, and an application layer that interact through abstract interfaces.

[0043] For the first type of smart devices, establishing a communication connection with the target smart device via Bluetooth Low Energy (BLE) means that the device discovery is handled by the Bluetooth Low Energy (BLE) technology at the connection layer. It has built-in timeout control and address deduplication mechanisms to avoid duplicate scanning and interference from invalid devices. After the target smart device is detected, the connection manager is responsible for establishing the BLE Generic Attribute Profile (GATT) connection, setting a 20-second connection timeout, automatically handling various connection status codes, and supporting up to three automatic reconnections. When GATT service discovery is complete and the onServicesDiscovered callback is triggered, the unified builder BtBuilder iterates through the universally unique identifier (UUID) of all GATT services, performing a switch match with the preset UUID-device type mapping table. If a match is found, the device category is determined, and the connection construction method (i.e., the builderConnect method) is called to create a concrete subclass of BaseDeviceReadWriteMgr (the transmission manager). The transmission manager automatically locates the read / write characteristic values ​​and enables the notification function in the setupService method. In the transport layer, the BLE side reads, writes, and sends / receives data using GATT feature values. After the transport manager is constructed, it automatically calls the `initDeviceMsgMg` method to initialize the device message manager. Internally, this calls the `builderMsg` method to build the message structure using a new `BtBuilder` instance. `builderMsg` performs switch dispatch based on the Bluetooth device type determined in the first phase, creating a corresponding concrete subclass of `BaseDeviceMsgMgr`, which is the protocol manager. After creation, the protocol manager is cached and reused; all subsequent data frames are directly dispatched to this instance for processing. In the protocol layer, the protocol manager serializes and parses data frames in a separate processing thread, avoiding data corruption and parsing errors caused by multi-threaded concurrency.

[0044] When an electronic device identifies a target smart device as a second-type smart device, it uses a transmission control protocol stack to complete the network connection process with that smart device. Specifically, this may include steps 1 to 10.

[0045] Step 1: Create a Socket and set connection parameters. Specifically, configure a connection timeout threshold for the TCP connection, such as 5 seconds, send buffer size, and receive buffer size, to avoid infinite waiting or memory overflow. This mechanism ensures rapid timeout failure when the network is unstable, rather than suspending and blocking other operations for a long time.

[0046] Step 2: Initiate a blocking connection request to the target smart device's IP:Port in a separate worker thread. Since the TCP three-way handshake process can take several seconds, the blocking connection request runs in a separate worker thread, which will not freeze the user interface thread or block communication from other devices.

[0047] Step 3: Connection Result Judgment. Specifically, if the connection is successfully established, proceed to steps 4 through 6 for normal communication; if the connection fails, proceed directly to steps 7 and 8 to perform the disconnection detection and resource cleanup process.

[0048] Step 4: Start a dedicated read thread to continuously read data returned by the target smart device. Immediately after the TCP connection is established, an independent loop read thread is created specifically for reading data from the InputStream. In this way, the read thread is responsible for receiving data, while the main thread / worker thread is responsible for writing data; the two do not block each other, achieving full-duplex communication.

[0049] Step 5: When sending a message, write it to the OutputStream in the worker thread. Before each message is sent, the socket manager checks whether the socket is still alive and whether the output stream is closed to avoid writing data to a disconnected connection. This pre-check mechanism can avoid IOExceptions in most cases and reduce unnecessary reconnection overhead.

[0050] Step 6, write exception detection. If no exception is thrown during the write process, continue sending the next message; if an IOException is caught, it is determined that the connection has been broken, and immediately proceed to steps 7 and 8 to perform the disconnection detection and resource cleanup process.

[0051] Step 7: Close all resources of the current connection. After an exception occurs, all resources of the old connection must be completely released, including Socket objects, input streams, output streams, and dedicated read threads. This ensures a clean initial state before each reconnection, preventing port leaks and file descriptor exhaustion caused by residual old connections.

[0052] Step 8: The user interface layer displays the disconnected status. In this way, by pushing the device's offline status to the user interface layer through the real-time data observer mode, users can see changes in the device's online status in real time and determine whether manual intervention is needed.

[0053] Step 9: Check if the current reconnection count has exceeded the maximum limit. Specifically, to avoid continuously wasting system resources and network bandwidth when the device is permanently offline, a maximum reconnection limit is set, such as 5 times. If the maximum reconnection limit is exceeded, reconnection will stop, the upper-layer device will be notified that the device is unreachable, and all associated resources will be released.

[0054] Step 10: Retry the connection after waiting using an exponential backoff strategy. Immediate reconnection will likely still fail, such as when the device is restarting. Therefore, an exponential backoff waiting time strategy can be used, such as waiting 3 seconds for the first attempt, 6 seconds for the second, 12 seconds for the third, and so on. This allows for quick restoration of briefly disconnected connections without causing network storms in scenarios with prolonged disconnections.

[0055] Step 11: Initiate a reconnection using the exact same parameters and process as the initial connection, and re-execute the connection process from Step 1 to Step 3 to ensure consistency in the reconnection behavior.

[0056] Step 12: Reconnection result assessment. Specifically, if the reconnection is successful, the reconnection counter is reset, and steps 4 to 6 are executed to restore normal communication; if the reconnection fails, the process returns to step 9 to continue retrying.

[0057] In this way, the transport layer writes data through the socket output stream and reads data through the input stream. To achieve transparency for upper-layer applications to the underlying communication protocol, the TCP side exposes a message sending and receiving interface that is completely consistent with the BLE channel. Upper-layer applications only need to call the unified interface to send and receive messages, without needing to know whether the underlying layer uses the TCP or BLE protocol for communication.

[0058] Therefore, electronic devices can intelligently select and use the most suitable communication protocol to establish a connection based on the specific type of the target smart device, which improves the success rate and efficiency of communication connection establishment, avoids connection failures caused by incompatible communication protocols, and ensures that electronic devices can establish stable and reliable communication with all target smart devices, thereby guaranteeing the smooth execution of scene services and user experience.

[0059] Then, regarding step 130, the device operation instruction refers to an instruction generated by the electronic device and sent to the target smart device. This device operation instruction is used to instruct the target smart device to perform a predetermined operation. The corresponding operation includes at least one of the following: an operation indicated by a device control instruction, or an operation indicated by a device status query instruction.

[0060] In some embodiments of this application, such as Figure 2 As shown, step 130 above may specifically include steps 1301 to 1303.

[0061] Step 1301: Generate equipment control instructions and equipment status query instructions according to the control scheme.

[0062] Device control commands are instructions given to target smart devices to perform specific actions. They have extremely high timeliness requirements; any delay will result in misaligned action execution. Examples include turning devices on / off and adjusting parameters. Specifically, device control commands can include control type, target smart device identifier, and specific control parameters. Device control commands can be generated based on preset control logic, user input, or sensor data. Device status query commands are used to instruct target smart devices to report their current operating status or parameters. They are frequent and numerous but allow for a certain delay. Examples include querying temperature, brightness, and on / off status. Specifically, device status query commands can include query type and target device identifier. Device status query commands can be generated periodically or when triggered by specific events, based on the user's needs for device status monitoring in the first scenario service.

[0063] Step 1302: Store the device control instructions in the first queue and the device status query instructions in the second queue according to the order of operation execution time.

[0064] The first queue, also known as the control message queue, is a data structure specifically used to cache device control commands to be sent. This first queue can be a first-in-first-out (FIFO) queue or a priority queue. The second queue, also known as the query message queue, is a data structure specifically used to cache device status query commands to be sent. This second queue can also be a FIFO queue or a priority queue.

[0065] In this step, two completely independent, physically isolated, thread-safe first-in-first-out (FIFO) queues are created during initialization: the first queue and the second queue. These two queues are completely separated in their memory address spaces, and their data structures do not affect each other, ensuring from the underlying design that the two types of messages will not interfere with each other. When external modules, such as the application layer, control logic modules, and sensor triggering modules, need to send messages, they are automatically routed to the corresponding queue based on the message type. That is, all device control commands enter the first queue, and all device status query commands enter the second queue. These two queues can be implemented using lock-free concurrent data structures, allowing multiple external modules to simultaneously submit messages to different queues. The submission operation and the retrieval operation of the sending thread do not block each other, supporting the command processing needs of high-concurrency scenarios.

[0066] Step 1303: According to the absolute priority polling strategy, extract device operation instructions from the first queue and the second queue, and send the device operation instructions to the corresponding target smart devices; the device operation instructions are device control instructions or device status query instructions. The absolute priority polling strategy includes a strategy of prioritizing the first queue in each polling cycle and only serving the second queue when the first queue is empty.

[0067] The absolute priority polling strategy prioritizes processing the first queue in each polling cycle, retrieving and sending device control commands from it. Only when the first queue is empty and contains no pending device control commands is the second queue processed, retrieving and sending device status query commands from it. As long as there are pending device control commands in the first queue, processing continues without switching to the second queue. The absolute priority polling strategy fixes the processing order of device control commands and device status query commands, ensuring that device control commands in the first queue are always retrieved and sent before device status query commands in the second queue. This fundamentally prevents lower-priority device status query commands from being sent before higher-priority device control commands, eliminating the possibility of priority reversal or queue jumping.

[0068] For example, the first queue includes device control command A and device control command B, and the second queue includes device status query command C and device status query command D. In the first polling cycle, since the first queue is not empty, device control command A is extracted from the head of the first queue first and sent to the corresponding target smart device. In the second polling cycle, the first queue still includes device control command B, so the first queue continues to be prioritized, extracting device control command B and sending it to the corresponding target smart device; at this time, the first queue becomes empty. In the third polling cycle, if the first queue is detected to be empty, the polling strategy switches to the second queue according to absolute priority, extracting device status query command C and sending it to the corresponding target smart device. In the fourth polling cycle, the first queue is still empty, so the second queue continues to be prioritized, extracting device status query command D and sending it to the corresponding target smart device. If a new device control command E enters the first queue while the second queue is being served, the first queue will be prioritized again at the next polling cycle. The device control command E will be extracted and sent to the corresponding target smart device, thus demonstrating the absolute priority of the first queue once again.

[0069] Therefore, device operation instructions are subdivided into device control instructions and device status query instructions, and physically isolated into two independent first-in-first-out queues. Combined with an absolute priority polling strategy for instruction extraction and transmission, this ensures that critical device control instructions can be processed first and responded to quickly, avoiding control delays caused by routine status queries, thereby significantly improving user experience and response efficiency.

[0070] In some embodiments of this application, step 1303 may specifically include: determining whether there are device control instructions to be sent in the first queue according to an absolute priority polling strategy; if there are device control instructions to be sent in the first queue, extracting the target device control instruction from the device control instructions to be sent according to a first-in-first-out rule, and sending the target device control instruction to the corresponding target smart device; or, if there are no device control instructions to be sent in the first queue, extracting the target device status query instruction from the device status query instructions to be sent in the second queue according to a first-in-first-out rule, and sending the target device status query instruction to the corresponding target smart device.

[0071] In this step, the control execution engine can start a dedicated, continuously looping send scheduling thread responsible for scheduling all instructions and sending work messages. The processing logic of each loop in this send scheduling thread strictly follows the following order: First, the sending scheduling thread accesses the head of the first queue to check if any device control commands are ready to be sent. Electronic devices can maintain an atomic state flag, which is updated in real time when commands are enqueued or dequeued. By querying this atomic flag, the sending scheduling thread can determine within nanoseconds whether the first queue is empty.

[0072] Secondly, if there are device control commands to be sent in the first queue, the first-in-first-out (FIFO) rule is followed, and the target device control command that was first enqueued in the first queue is retrieved and immediately sent to the corresponding target smart device. After sending, the sending scheduling thread jumps directly back to the beginning of the loop and starts checking from the first queue again, without accessing the second queue at all.

[0073] Furthermore, the second queue is only processed when the first queue is empty: if there are no device control commands to be sent in the first queue, the sending scheduling thread will switch to the second queue, retrieve the first enqueued target device status query command from the head of the second queue according to the first-in-first-out rule, and send it to the corresponding target smart device. After sending is complete, it returns to the beginning of the loop.

[0074] In addition, after each device operation command is sent, the sending scheduling thread waits briefly for a preset fixed time interval, such as 70 milliseconds, to allow the smart device the minimum instruction processing time window, preventing the smart device from overflowing and responding abnormally due to excessively dense instructions. After the wait is over, it returns to the beginning of the loop to continue the next round of scheduling until the current loop reaches the preset number of loops. At this point, the execution of the current control strategy is automatically terminated, the independent sending scheduling thread is destroyed, and an execution completion notification is sent to the upper-layer application module.

[0075] Furthermore, the control execution engine maintains the current execution state of the target smart device during execution, such as running, paused, or completed. It supports users sending stop commands to interrupt execution at any time, and releases the occupation mark on the target smart device after execution ends or is interrupted, allowing other device control strategies to take over control of these smart devices.

[0076] Therefore, by employing a clear absolute priority polling strategy, high-priority device control commands are ensured to be processed and sent immediately, significantly improving the response speed and control accuracy of intelligent devices to user operations. Simultaneously, when there are no high-priority control tasks, electronic devices can promptly process low-priority device status query commands, avoiding delays in status information acquisition and ensuring comprehensive awareness of device operating status. This effectively resolves command scheduling conflicts in scenarios with concurrent multi-type commands and optimizes the utilization efficiency of communication resources.

[0077] In some embodiments of this application, such as Figure 3 As shown, the above-mentioned intelligent device control method may further include steps 140 to 160.

[0078] Step 140: At preset time intervals, determine whether there are any device status query commands to be sent in the second queue.

[0079] The preset time interval is a configurable periodic parameter that can be set according to the actual application scenario, the number of devices, network load, or the user's requirements for real-time status. For example, it can be set to several seconds, tens of seconds, or several minutes.

[0080] Step 150: If there are no device status query instructions to be sent in the second queue, generate a new device status query instruction corresponding to each target smart device one by one according to the protocol format corresponding to at least two target smart devices.

[0081] In this step, the electronic device can initiate an independent auto-fill thread for query commands. This thread runs at fixed preset time intervals, such as every 8 seconds, and is specifically responsible for checking the status of the second queue and filling messages. This thread is completely independent of the message sending scheduling thread and does not interfere with each other. If the auto-fill thread finds no device status query commands to be sent in the second queue, the electronic device will iterate through all connected target smart devices and generate a device status query command independently for each target smart device. During the generation of device status query commands, the auto-fill thread will automatically select the corresponding protocol template based on the device type and communication protocol identified in the previous step, and fill in the status query command word, target device identifier, checksum, and other necessary protocol fields. This ensures that when the control queue is idle, the electronic device can continuously poll the device's operating status during the idle periods of the sending thread.

[0082] Step 160: Store the new device status query command in the second queue.

[0083] In this step, the newly generated device status query commands are added to the tail of the second queue in the order they were generated.

[0084] Therefore, by having electronic devices periodically and proactively generate and send status query commands, the problem of delayed or incomplete device status information caused by the lack of a proactive query mechanism is effectively avoided. This ensures that electronic devices can continuously obtain the latest operating status of all target intelligent devices. This significantly improves the real-time performance, accuracy, and comprehensiveness of device status management, enabling electronic devices to make decisions and controls based on more reliable status data, thereby enhancing the stability of the entire intelligent device control system.

[0085] In some embodiments of this application, the electronic device includes at least two data buffers, with one data buffer corresponding to one target smart device. The data buffers of different smart devices are completely isolated in memory address space, and data read and write operations do not interfere with each other. The at least two target smart devices include a second type of smart device, which is a device that supports the Transmission Control Protocol (TCP). The TCP is a byte-stream-oriented transport layer protocol that does not preserve application layer message boundaries. Multiple independent protocol frames sent by the application layer at the sending end may be automatically merged or split by the operating system's TCP / IP protocol stack according to network conditions during network transmission, leading to three typical message boundary disorder phenomena at the receiving end: packet merging, incomplete packet generation, and frame misalignment.

[0086] Among these, packet merging refers to multiple complete application layer protocol frames being combined into a single TCP segment and arriving at the receiving end in a single Socket read operation, making it impossible for the receiving end to directly distinguish the logical boundaries between the frames; incomplete packet generation refers to a complete application layer protocol frame being split into multiple TCP segments and arriving at the receiving end in two or more Socket read operations, where the data read in any single operation cannot form a complete parsable frame; frame misalignment refers to the situation where, due to network jitter, out-of-order packet transmission, or disordered local buffer data, the received data stream does not start at the header of a complete protocol frame, but rather from the middle data byte of a frame. Furthermore, the firmware of some older smart devices has defects in message sending logic, which may produce abnormal data such as incomplete frame structures and incorrect data field offsets. Directly parsing using a fixed offset method will yield completely incorrect results.

[0087] Based on this, such as Figure 4 As shown, the above-mentioned intelligent device control method may further include steps 170 to 190.

[0088] Step 170: Upon receiving new byte data from the second type of smart device, store the new byte data in the data buffer corresponding to the second type of smart device.

[0089] In this step, a dedicated persistent data buffer is pre-allocated to each Type II smart device. This data buffer persists throughout the entire connection period with the Type II smart device and is not destroyed after a single data read. When the electronic device receives any byte data from a specific Type II smart device via the network interface, this byte data is not immediately parsed but is appended to the end of the dedicated data buffer for that Type II smart device. Thus, if there are any unprocessed, incomplete half-frames after the previous frame parsing, these half-frames are automatically retained in the data buffer. When new data is appended, the two parts naturally connect to form a continuous byte stream, ensuring that subsequent parsing always deals with a complete and continuous data stream starting from the previous remaining position. This prevents context loss due to data arriving in batches, fundamentally solving the data fragmentation problem caused by the streaming nature of the TCP protocol.

[0090] Step 180: If the total length of the byte data stream in the data buffer is greater than or equal to the preset protocol frame data length, perform frame parsing processing on the byte data stream in the data buffer to obtain the frame parsing result. The byte data stream is determined based on the new byte data and the residual byte data already stored in the data buffer. The new byte data is appended to the end of the residual byte data.

[0091] In this step, the electronic device continuously monitors the amount of accumulated bytes in each data buffer. Once the total amount of data in a data buffer reaches or exceeds the pre-defined minimum frame length of a protocol frame (i.e., the total number of bytes in the frame header identifier, length field, and checksum field), frame parsing logic is triggered. Conversely, if the total amount of data in the data buffer is less than the pre-defined minimum frame length of a protocol frame, it means that the bytes in the data buffer cannot form any complete frame. The buffer contents are retained and the device exits, waiting for the next batch of data to arrive before reassembling. In this way, obviously incomplete data can be filtered out at a very low cost, avoiding time-consuming frame parsing and verification logic. For example, if the minimum length of a protocol frame is 64 bytes, when the data in the data buffer reaches 64 bytes, the frame parser logically concatenates the newly received bytes with the residual bytes that were previously retained in the buffer due to incomplete frames, forming a complete byte data stream. For example, if a 100-byte data frame arrives in two parts, with the first 50 bytes as residual data and the second 50 bytes as new data, the parser will treat these two parts as a single 100-byte continuous stream.

[0092] Step 190: Determine the processing method for the byte data stream based on the frame parsing results.

[0093] Therefore, electronic devices can effectively process streaming data from Type II smart devices, ensuring accurate identification and parsing of complete protocol frames even under unstable network transmission conditions. This significantly improves the reliability of device control and the robustness of data processing, avoiding problems such as device control command execution failures or false status information reports due to incomplete or erroneous data frames. Consequently, scenario-based smart device control becomes more stable and accurate, enhancing the user experience.

[0094] In some embodiments of this application, such as Figure 5 As shown, step 180 above may specifically include steps 1801 to 1805.

[0095] Step 1801: Extract the frame header identifier field and the frame data length identifier field from the byte data stream in the data buffer.

[0096] The frame header identifier field is a specific sequence of bytes used to mark the start of a data frame and serves as the basis for electronic devices to identify data frame boundaries. The frame data length identifier field indicates the total length of the current data frame and is used to determine the complete range of a data frame.

[0097] In this step, a sliding parsing pointer mechanism can be used. The parsing pointer initially points to the beginning position of the data buffer, and the pointer moves according to the parsing result after each parsing, so as to achieve uninterrupted parsing of continuous byte streams.

[0098] Step 1802: Detect whether the frame header identifier field conforms to the preset frame header identifier characteristics, and obtain the frame header detection result.

[0099] In this step, the extracted frame header identifier field is matched against one or more preset, valid frame header feature values. If the frame header identifier field completely matches any preset valid frame header feature value, the frame header detection result is passed; otherwise, the frame header detection result is failed. When the frame header detection fails, the current parsing pointer is moved forward by 1 byte, and the process returns to step 1801 to restart the frame header detection until a valid frame header is found or the entire data buffer is traversed.

[0100] Step 1803: If the frame header detection result is passed, check whether the actual data length of the byte data stream is greater than or equal to the declared data length corresponding to the frame data length identifier field, and obtain the data length verification result.

[0101] In this step, if the frame header detection passes, the actual usable data length from the parsing pointer position to the end of the buffer is calculated. This actual usable data length is then compared with the declared data length corresponding to the frame data length identifier field to obtain the data length verification result. If the actual usable data length is greater than or equal to the declared data length, the data length verification result is passed; if the actual usable data length is less than the declared data length, the data length verification result is failed. When the data length verification fails, the current parsing pointer position remains unchanged, the current frame parsing process is terminated, and parsing is triggered again after receiving more data.

[0102] Step 1804: If the data length check result is passed, perform integrity check on the byte data within the declared data length in the byte data stream to obtain the data integrity check result.

[0103] In this step, if the data length check passes, a complete data segment with a length equal to the declared data length, starting from the parsed pointer position, is extracted from the byte data stream. An integrity check operation is performed on this data segment to obtain the data integrity check result. This integrity check operation includes, but is not limited to, XOR check, cyclic redundancy check, and summation check, with the specific check method consistent with the communication protocol. The check operation covers all bytes from the frame header identifier field to the check field. The calculated check value is compared with the check field value carried at the end of the data frame: if they match exactly, the data integrity check passes; otherwise, the data integrity check fails.

[0104] Step 1805: Determine the frame parsing result based on the frame header detection result, data length verification result, and data integrity verification result.

[0105] The frame parsing result includes at least one of the following: frame parsing success, frame data incompleteness, or frame parsing failure. A frame parsing success state means that one or more complete and valid data frames have been successfully identified and extracted from the byte data stream in the data buffer. A frame data incompleteness state means that the byte data stream in the current data buffer is insufficient to constitute a complete protocol frame; for example, the length of the received data is less than the data length declared in the protocol frame header. A frame parsing failure state means that even if the data length may be sufficient, a valid protocol frame could not be successfully identified from the byte data stream in the data buffer.

[0106] In this step, when the frame header detection result, data length verification result, and data integrity verification result all pass, the frame parsing result is determined to be a successful frame parsing state; when the frame header detection result passes but the data length verification result fails, the frame parsing result is determined to be a frame data incomplete state; when the frame header detection result fails or the data integrity verification result fails, the frame parsing result is determined to be a failed frame parsing state.

[0107] Therefore, when electronic devices perform frame parsing on the byte data stream in the data buffer, they can quickly identify and filter out invalid data frames by extracting and detecting the frame header identifier field, ensuring that the data processed subsequently is the beginning part that conforms to the protocol specification. Furthermore, by verifying the consistency between the actual data length and the declared data length of the byte data stream, parsing anomalies caused by incomplete data can be effectively avoided, ensuring the security of data processing. In addition, performing integrity checks on the byte data within the declared data length can promptly detect potential damage or tampering during transmission, thereby ensuring the accuracy of the data content. Combining these verification results, the frame parsing result can be accurately determined, providing a reliable basis for subsequent handling of the byte data stream, significantly improving the stability of communication with smart devices and the reliability of data processing.

[0108] In some embodiments of this application, such as Figure 6 As shown, step 190 above may specifically include steps 1901 to 1903.

[0109] Step 1901: If the frame parsing result includes a frame parsing success status, the first processing method is determined to be the processing method for the byte data stream. The first processing method is to generate device operation status information displayed on the display interface based on the single frame byte data stream in the byte data stream.

[0110] In this step, if the frame parsing result is a successful frame parsing state, the first processing method includes: extracting the complete frame data from the data buffer and submitting it to the upper-layer protocol processing module for business logic processing, generating device operating status information and updating the display interface; truncating the processed complete frame data from the data buffer, leaving the remaining unprocessed data at the beginning of the buffer; if the length of the remaining bytes in the data buffer is greater than or equal to the minimum frame length, then using the remaining data as the new parsing object, recursively returning to step 1801 to continue parsing the next frame. This ensures that multiple contiguous frames contained in a single TCP read are completely disassembled one by one without any omissions. For example, when reading data containing 3 complete contiguous frames, it will be recursively parsed 3 times until the remaining data in the buffer is less than a complete frame.

[0111] In this way, when the data frame is complete and valid, device operating status information can be generated and displayed promptly and accurately, improving the user's ability to perceive the status of the smart device. When the data frame is incomplete, the electronic device can intelligently pause parsing and wait for subsequent data, avoiding invalid processing and resource waste, and ensuring the continuity and integrity of data processing.

[0112] Step 1902: If the frame parsing result includes an incomplete frame data state, the second processing method is determined to be the processing method for the byte data stream. The second processing method is to exit the current frame parsing process and wait to receive new byte data sent by the second type of smart device.

[0113] In this step, if the frame parsing result is that the frame data is incomplete, the second handling method includes: keeping the buffer content completely unchanged, without making any interception or modification, directly exiting the current frame parsing process, waiting for the TCP read thread to receive the next batch of new byte data, and then re-executing the complete process of steps 170 to 190.

[0114] Step 1903: If the frame parsing result includes a frame parsing failure state, the third handling method is determined to be the handling method for the byte data stream. The third handling method is to recursively execute the frame parsing processing steps on the target byte data stream in the data buffer. The target byte data stream is the remaining byte data after sliding a preset number of bytes backward from the starting position in the byte data stream of the data buffer.

[0115] In this step, if the frame parsing result is a frame parsing failure, the third handling method includes: sliding the buffer backward by a minimum step size, i.e., 1 byte, discarding the first byte, and using the remaining byte data stream after the slide as the new parsing object, recursively returning to step 1801 to retry matching the frame header from the new position. Since the exact length of the erroneous data cannot be predicted, sliding only 1 byte at a time is the most conservative fault-tolerance strategy. A 1-byte slide ensures that the starting position of any correct frame is not mistakenly skipped. In the worst case and under conditions of continuous erroneous data, the algorithm will scan the entire buffer byte by byte until the next valid frame header is found, thereby maximizing the data recovery rate and effectively solving the parsing interruption problem caused by frame misalignment and abnormal data from older devices.

[0116] In this way, when frame parsing fails, the electronic device can attempt to recover from the erroneous data stream and find the next possible valid frame by recursively sliding the data buffer. This significantly enhances the fault tolerance and robustness of data processing, effectively avoids the problem of interrupting the entire data stream processing due to local data errors, and thus improves the stability and reliability of the intelligent device control system.

[0117] Thus, in scenarios where multiple frames arrive consecutively due to packet fragmentation, recursion is used to disassemble each frame without omission. In scenarios with incomplete packets, incomplete frames automatically wait for subsequent data, without false alarms or data loss. In scenarios with frame misalignment, a byte-by-byte search is performed with the smallest granularity to maximize the restoration to the correct frame synchronization state.

[0118] Therefore, when processing byte data sent by second-type smart devices, electronic devices can adopt precise and efficient differentiated processing strategies based on the actual results of frame parsing, realizing complete encapsulation of message boundary issues at the lower level. Upper-layer business modules only need to receive complete and valid frames that have passed verification, without having to handle any inherent boundary issues of the TCP protocol themselves.

[0119] In some embodiments of this application, the electronic device adopts a layered and decoupled architecture design, specifically including: a user interface layer, a solution engine layer, a protocol layer, a queue layer, a scheduling layer, and a transport layer. The layers interact with each other through message passing, facilitating independent maintenance, expansion, and replacement.

[0120] The following section will explain the aforementioned device control information in conjunction with the layered decoupling architecture of electronic devices.

[0121] Step 11: Upon receiving user input, the user interface layer transmits the intent information corresponding to the user input to the solution engine layer.

[0122] In this step, the user selects the first scenario service and clicks the "Start Execution" button in the device control policy management interface of the in-vehicle central control screen. The user interface layer uses a real-time data observer pattern to pass the user's input intent information from the user interface thread to the solution engine in a separate background worker thread.

[0123] Step 12: The solution engine layer parses the intent information and generates a sequence of device operation instructions.

[0124] In this step, after receiving the intent information, the solution engine layer retrieves the pre-configured device control policy corresponding to the first scenario service identifier from the pre-configured policy database through the control execution engine. It then parses the policy to obtain core configuration parameters such as the target device list, action sequence, timing parameters, and loop count. The abstract control scheme definition is then expanded into a sequence of directly executable device operation instructions arranged in execution order. Simultaneously, the solution engine layer creates a completely independent worker thread for this execution. This thread is completely isolated from the system main thread, user interface thread, and execution threads of other control schemes, and is unaffected by fluctuations in other thread scheduling, laying the foundation for subsequent precise timing control.

[0125] Step 13: The solution engine layer transmits the device operation command sequence to the protocol layer.

[0126] In this step, the solution engine layer passes the generated sequence of device operation instructions to the protocol layer. The protocol layer automatically selects the corresponding protocol encoder based on the communication protocol type of the target smart device, and then encodes the corresponding device operation instructions into a standard binary message format recognizable by the target smart device.

[0127] Step 14: The protocol layer sends the encoded device operation command to the queue layer.

[0128] In this step, the queue layer creates two completely independent, physically isolated, thread-safe queues during initialization. The first queue is dedicated to carrying all device control commands and has the highest transmission priority; the second queue is dedicated to carrying all device status query commands and has a lower transmission priority. The queue layer routes device control commands from the encoded device operation commands to the first queue, and routes device status query commands from the encoded device operation commands to the second queue.

[0129] Step 15: The scheduling layer extracts the encoded device operation instructions from the queue layer.

[0130] In this step, the scheduling layer runs a dedicated, independent scheduling thread that employs an absolute priority round-robin strategy: during each round of scheduling, the scheduling thread first checks if there are any messages waiting to be sent in the first queue. If there are messages in the first queue, the message at the head of the queue is immediately retrieved and sent; only when the first queue is empty will the scheduling thread process messages in the second queue, to ensure the absolute sending priority of control commands.

[0131] Step 16: The scheduling layer transmits the extracted and encoded device operation instructions to the transport layer.

[0132] In this step, the scheduling layer extracts the encoded device operation instructions, and the transport layer automatically selects the corresponding transmission channel based on the type of the target smart device. The encoded device operation instructions are then written to the corresponding transmission channel through a unified message sending interface. Here, the scheduler is only responsible for message scheduling logic; the actual IO read / write operations are entirely executed independently by the transport layer. The transport layer can independently switch or upgrade its TCP / BLE communication implementation without requiring any modification to the upper-layer scheduling and business logic. Furthermore, the transport layer incorporates the aforementioned TCP automatic reconnection mechanism and BLE connection management mechanism, automatically handling issues such as connection drops and network anomalies to ensure reliable message transmission.

[0133] Step 17: The transport layer sends the corresponding binary byte stream to the target smart device via TCP Socket or BLE signature write operation.

[0134] In this step, after the communication module of the target smart device receives the complete data frame, it hands it over to the control unit inside the target smart device to execute the corresponding control action.

[0135] Step 18: The target intelligent device sends the control action execution result to the transport layer.

[0136] In this step, after the target smart device completes the control action, it encapsulates the control action execution result and / or device status information into a response packet according to the same protocol format and sends it back to the electronic device. The transport layer monitors the transmission channel in real time through a continuously running dedicated read thread to receive the response packet data returned by the target smart device as soon as possible.

[0137] Step 19: The transport layer transmits the control action execution results to the protocol layer.

[0138] In this step, the transport layer transmits the received raw byte stream to the protocol layer for frame parsing. After parsing, the protocol layer distributes the complete data frame to the corresponding protocol decoder based on the frame header prefix, converting the decoded binary data into structured data that can be understood by the upper layers.

[0139] Step 20: The protocol layer transmits the control action execution result to the user interface layer.

[0140] In this step, the user interface layer updates the user interface based on the structured data transmitted by the transport layer using a real-time data observer pattern. This allows users to see device status changes and the progress of control scheme execution in real time without manually refreshing the interface, resulting in a better interactive experience.

[0141] Furthermore, once all control commands in a sequence of actions have been executed and feedback has been received from the target smart device, the solution engine will check whether the current loop has reached the preset number of loops. If the preset number of loops has not been reached, the current loop will be incremented by 1, and the process from steps 2 to 9 above will be repeated to start the next loop execution. If the preset number of loops has been reached, the execution of this control solution will automatically end, the independent working thread will be destroyed, and an execution completion notification will be sent to the user through the user interface layer.

[0142] Based on the intelligent device control method provided in the above embodiments, this application also provides specific implementations of an intelligent device control apparatus. Please refer to the following embodiments.

[0143] See Figure 7 The intelligent device control device 20 provided in this application embodiment is applied to an electronic device. The intelligent device control device includes: an acquisition module 201, a connection module 202, and a transmission module 203.

[0144] The acquisition module 201 is used to acquire the device control strategy corresponding to the first scenario service when it receives the user's input of selecting the first scenario service; the device control strategy includes at least two target smart devices and control schemes corresponding to the at least two target smart devices; the connection module 202 is used to establish communication connections with the at least two target smart devices respectively based on the device control strategy; the sending module 203 is used to send device operation instructions to each target smart device according to the control scheme; the device operation instructions are used to instruct the target smart devices to perform corresponding operations.

[0145] Therefore, when the electronic device receives the user's input of selecting the first scenario service through the acquisition module 201, it can obtain the corresponding device control strategy. Then, the connection module 202 automatically establishes communication connections with multiple target intelligent devices based on the device control strategy, and sends device operation instructions to the target intelligent devices according to the control scheme through the sending module 203. This eliminates the need for the user to manually configure connections, filter intelligent devices, and send device operation instructions one by one, which simplifies the operation process of multi-intelligent device collaborative control, improves the control efficiency of intelligent devices, and effectively solves the problems of cumbersome process and low control efficiency of existing multi-intelligent device collaborative control.

[0146] In some embodiments of this application, the sending module 203 can be used to: generate device control instructions and device status query instructions according to the control scheme; store the device control instructions in a first queue and the device status query instructions in a second queue according to the order of operation execution time; extract device operation instructions from the first queue and the second queue according to an absolute priority polling strategy, and send the device operation instructions to the corresponding target smart device; the device operation instructions are device control instructions or device status query instructions, and the absolute priority polling strategy includes a strategy of prioritizing the first queue in each polling cycle and only serving the second queue when the first queue is empty.

[0147] In some embodiments of this application, the sending module 203 can also be used to: determine whether there are device control instructions to be sent in the first queue according to an absolute priority polling strategy; if there are device control instructions to be sent in the first queue, extract the target device control instruction from the device control instructions to be sent according to the first-in-first-out rule, and send the target device control instruction to the corresponding target smart device; or, if there are no device control instructions to be sent in the first queue, extract the target device status query instruction from the device status query instructions to be sent in the second queue according to the first-in-first-out rule, and send the target device status query instruction to the corresponding target smart device.

[0148] In some embodiments of this application, the above-described intelligent device control device 20 may further include a determination module, a generation module, and a storage module.

[0149] The determination module is used to determine whether there is a device status query instruction to be sent in the second queue at preset time intervals; the generation module is used to generate a new device status query instruction corresponding to each target smart device in accordance with the protocol format corresponding to at least two target smart devices when there is no device status query instruction to be sent in the second queue; the storage module is used to store the new device status query instruction to the second queue.

[0150] In some embodiments of this application, the connection module 202 is used to: determine the priority order of at least two target smart devices based on the device priority information in the device control strategy; and establish communication connections with at least two target smart devices in descending order of priority.

[0151] In some embodiments of this application, at least two target smart devices include at least one of the following: a first type of smart device and a second type of smart device; the first type of smart device is a device that supports Bluetooth Low Energy protocol, and the second type of smart device is a device that supports Transmission Control Protocol; based on this, the connection module 203 is further configured to: establish a communication connection with the target smart device via Bluetooth Low Energy protocol when the target smart device is a first type of smart device; and establish a communication connection with the target smart device via Transmission Control Protocol when the target smart device is a second type of smart device.

[0152] In some embodiments of this application, the electronic device includes at least two data buffers, one data buffer corresponding to one target smart device, and the at least two target smart devices include a second type of smart device, which is a device that supports the transmission control protocol; the aforementioned smart device control device may also include a frame parsing module.

[0153] The frame parsing module is used to store new byte data sent by the second type of smart device in the data buffer corresponding to the second type of smart device when it receives new byte data; when it is determined that the total length of the byte data stream in the data buffer is greater than or equal to the preset protocol frame data length, the module performs frame parsing processing on the byte data stream in the data buffer to obtain the frame parsing result. The byte data stream is determined based on the new byte data and the residual byte data already stored in the data buffer, and the new byte data is appended to the end of the residual byte data; the module determines the processing method for the byte data stream based on the frame parsing result.

[0154] In some embodiments of this application, the frame parsing module is used to extract a frame header identifier field and a frame data length identifier field from the byte data stream in the data buffer; detect whether the frame header identifier field conforms to a preset frame header identifier feature to obtain a frame header detection result; if the frame header detection result is successful, check whether the actual data length of the byte data stream is greater than or equal to the declared data length corresponding to the frame data length identifier field to obtain a data length verification result; if the data length verification result is successful, perform an integrity check on the byte data in the byte data stream that is within the declared data length to obtain a data integrity verification result; and determine the frame parsing result based on the frame header detection result, the data length verification result, and the data integrity verification result.

[0155] In some embodiments of this application, the frame parsing result includes at least one of the following: frame parsing success state, frame data incomplete state, and frame parsing failure state. Based on this, the frame parsing module is further configured to: when the frame parsing result includes a frame parsing success state, determine a first processing method as a processing method for byte data streams, wherein the first processing method is to generate device operating status information displayed on the display interface based on a single frame byte data stream in the byte data stream; when the frame parsing result includes a frame data incomplete state, determine a second processing method as a processing method for byte data streams, wherein the second processing method is to exit the current frame parsing process and wait to receive new byte data sent by the second type of smart device; when the frame parsing result includes a frame parsing failure state, determine a third processing method as a processing method for byte data streams, wherein the third processing method is to recursively execute frame parsing processing steps on the target byte data stream in the data buffer, wherein the target byte data stream is the remaining byte data after sliding a preset number of bytes backward from the starting position in the byte data stream of the data buffer.

[0156] The various modules of the intelligent device control device 20 provided in this application embodiment can realize Figures 1 to 5 The functions of each step in the provided intelligent device control method, and the corresponding technical effects they achieve, will not be elaborated here for the sake of brevity.

[0157] Figure 8 The diagram shows a schematic representation of the hardware structure of an electronic device provided in some embodiments of this application.

[0158] The electronic device 30 may include a processor 301 and a memory 302 storing computer program instructions.

[0159] Specifically, the processor 301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0160] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 302 may include removable or non-removable (or fixed) media. Where appropriate, memory 302 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 302 is non-volatile solid-state memory.

[0161] In certain embodiments, memory 302 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory 302 includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the intelligent device control method in the above embodiments according to this application.

[0162] The processor 301 reads and executes computer program instructions stored in the memory 302 to implement any of the intelligent device control methods in the above embodiments.

[0163] In one example, electronic device 30 may further include communication interface 303 and bus 310. Wherein, as Figure 8 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 310 and complete communication with each other.

[0164] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0165] Bus 310 includes hardware, software, or both, that couples components of electronic device 30 together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count Bus (LPC), a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VESA Local Bus, VLB), or other suitable buses, or a combination of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0166] The electronic device 30 can execute the intelligent device control method in the embodiments of this application, thereby achieving the combination Figures 1 to 7 The intelligent device control method and apparatus are described.

[0167] Furthermore, in conjunction with the intelligent device control methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the intelligent device control methods in the above embodiments. Examples of computer-readable storage media include non-transitory computer-readable storage media, such as portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, etc.

[0168] Furthermore, in conjunction with the intelligent device control methods in the above embodiments, this application embodiment can provide a computer program product for implementation. This program product is stored in a storage medium and may specifically include a computer program or instructions. When executed by a processor, the computer program or instructions implement any of the intelligent device control methods in the above embodiments. This program product is executed by at least one processor to implement the various processes as described in the above data processing method embodiments, and can achieve the same technical effects. To avoid repetition, further details are omitted here.

[0169] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0170] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this disclosure are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable read-only memory (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0171] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0172] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0173] The above description is merely a specific embodiment of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for controlling an intelligent device, characterized in that, Applied to electronic devices, including: Upon receiving input from a user selecting a first scenario service, the system obtains a device control strategy corresponding to the first scenario service; the device control strategy includes at least two target smart devices and a control scheme corresponding to the at least two target smart devices. Based on the device control strategy, communication connections are established with the at least two target intelligent devices respectively; According to the control scheme, a device operation instruction is sent to each of the target intelligent devices; the device operation instruction is used to instruct the target intelligent device to perform a corresponding operation.

2. The method according to claim 1, characterized in that, Sending device operation instructions to the target intelligent device according to the control scheme includes: According to the control scheme, generate equipment control commands and equipment status query commands; According to the order of operation execution time, the device control instructions are stored in the first queue, and the device status query instructions are stored in the second queue; According to the absolute priority polling strategy, device operation instructions are extracted from the first queue and the second queue, and the device operation instructions are sent to the corresponding target smart devices. The device operation instructions are either device control instructions or device status query instructions. The absolute priority polling strategy includes a strategy of prioritizing the first queue in each polling cycle and only serving the second queue when the first queue is empty.

3. The method according to claim 2, characterized in that, The step of extracting device operation instructions from the first queue and the second queue according to an absolute priority polling strategy, and sending the device operation instructions to the corresponding target smart device, includes: According to the absolute priority polling strategy, determine whether there are any device control commands to be sent in the first queue; If there are device control instructions to be sent in the first queue, the target device control instruction is extracted from the device control instructions to be sent according to the first-in-first-out rule, and the target device control instruction is sent to the corresponding target smart device. Alternatively, if the device control command to be sent is not in the first queue, the target device status query command is extracted from the device status query commands to be sent in the second queue according to the first-in-first-out rule, and the target device status query command is sent to the corresponding target smart device.

4. The method according to claim 2 or 3, characterized in that, The method further includes: At preset time intervals, determine whether there are any device status query commands to be sent in the second queue; If there is no device status query instruction to be sent in the second queue, generate a new device status query instruction corresponding to each target smart device one by one according to the protocol format corresponding to the at least two target smart devices; The new device status query instruction is stored in the second queue.

5. The method according to claim 1, characterized in that, The step of establishing communication connections with the at least two target smart devices based on the device control strategy includes: Based on the device priority information in the device control strategy, determine the priority order of the at least two target intelligent devices; Communication connections with the at least two target smart devices are established sequentially in descending order of priority.

6. The method according to any one of claims 1 to 3 and 5, characterized in that, The at least two target smart devices include at least one of the following: a first type of smart device and a second type of smart device; the first type of smart device is a device that supports the Bluetooth Low Energy protocol, and the second type of smart device is a device that supports the Transmission Control Protocol. Establishing a communication connection with the at least two target smart devices includes: When the target smart device is the first type of smart device, a communication connection is established with the target smart device via Bluetooth Low Energy protocol; If the target smart device is a second type of smart device, a communication connection is established with the target smart device through a transmission control protocol.

7. The method according to any one of claims 1 to 3 and 5, characterized in that, The electronic device includes at least two data buffers, with one data buffer corresponding to one target intelligent device. The at least two target intelligent devices include a second type of intelligent device, which is a device that supports a transmission control protocol. The method further includes: Upon receiving new byte data sent by the second type of smart device, the new byte data is stored in the data buffer corresponding to the second type of smart device; If the total length of the byte data stream in the data buffer is greater than or equal to the preset protocol frame data length, the byte data stream in the data buffer is subjected to frame parsing processing to obtain a frame parsing result. The byte data stream is determined based on the new byte data and the residual byte data already stored in the data buffer. The new byte data is appended to the end of the residual byte data. Based on the frame parsing results, determine the processing method for the byte data stream.

8. The method according to claim 7, characterized in that, The step of performing frame parsing processing on the byte data stream in the data buffer to obtain the frame parsing result includes: Extract the frame header identifier field and the frame data length identifier field from the byte data stream in the data buffer; Detect whether the frame header identifier field conforms to the preset frame header identifier characteristics to obtain the frame header detection result; If the frame header detection result is passed, check whether the actual data length of the byte data stream is greater than or equal to the declared data length corresponding to the frame data length identifier field to obtain the data length verification result. If the data length verification result is passed, integrity verification is performed on the byte data in the byte data stream that is within the declared data length to obtain the data integrity verification result. The frame parsing result is determined based on the frame header detection result, the data length verification result, and the data integrity verification result.

9. The method according to claim 7, characterized in that, The frame parsing result includes at least one of the following: frame parsing success status, frame data incomplete status, and frame parsing failure status. The step of determining the processing method for the byte data stream based on the frame parsing result includes: If the frame parsing result includes the frame parsing success status, the first processing method is determined to be the processing method for the byte data stream. The first processing method is to generate device operating status information displayed on the display interface based on the single frame byte data stream in the byte data stream. If the frame parsing result includes a state where the frame data is incomplete, the second processing method is determined to be the processing method for the byte data stream. The second processing method is to exit the current frame parsing process and wait to receive new byte data sent by the second type of smart device. If the frame parsing result includes the frame parsing failure state, the third handling method is determined as the handling method for the byte data stream. The third handling method is to recursively execute the frame parsing processing steps on the target byte data stream in the data buffer. The target byte data stream is the remaining byte data after sliding a preset number of bytes backward from the starting position in the byte data stream of the data buffer.

10. A smart device control device, characterized in that, Applied to electronic devices, the device includes: The acquisition module is used to acquire the device control policy corresponding to the first scenario service when it receives input from the user selecting the first scenario service; the device control policy includes at least two target smart devices and control schemes corresponding to the at least two target smart devices; A connection module is used to establish communication connections with the at least two target smart devices based on the device control strategy. The sending module is used to send device operation instructions to each of the target smart devices according to the control scheme; the device operation instructions are used to instruct the target smart devices to perform corresponding operations.

Images