Equipment discovery method and device

Abstract

The embodiment of the invention provides an equipment discovery method and device, relates to the technical field of electronic equipment, and can discover IOT equipment under the condition that the IOT equipment is not integrated with an SDK (Software Development Kit). And furthermore, the IOT equipment can be managed and controlled. The method comprises: in response to a first operation of a user, an electronic device scans hotspot information of Internet of Things devices in a communication range, the Internet of Things devices in the communication range comprising a first Internet of Things device, and the hotspot information of the first Internet of Things device comprising an SSID of the first Internet of Things device; the AP hotspot of the first Internet of Things equipment is normally open, and the first Internet of Things equipment is not networked; the electronic device displays a first interface, the first interface comprises a target card, and the target card is used for prompting discovery of the Internet of Things device.

Description

Technical Field

[0001] This application relates to the field of electronic device technology, and in particular to a device discovery method and apparatus. Background Technology

[0002] With the development of Internet of Things (IoT) technology, more and more IoT devices have appeared on the market, such as robot vacuums, table lamps, door locks, speakers, and air conditioners. Users can discover and manage these IoT devices through electronic devices (such as mobile phones).

[0003] Since different IoT devices may come from different manufacturers, related technologies allow IoT device manufacturers to configure software development kits (SDKs) developed by electronic device manufacturers into the IoT devices. Electronic devices can then discover and manage IoT devices based on the SDKs integrated into the IoT devices.

[0004] However, some IoT devices (such as visual ear-cleaning devices, action cameras, camera glasses, and dashcams) are not easy to integrate SDKs and other binary files due to limited resources (e.g., small memory and poor chip capabilities). How to discover and manage these IoT devices that are not easy to integrate SDKs has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides a device discovery method and apparatus that can discover IoT devices even when they do not integrate an SDK. Furthermore, it enables the management and control of IoT devices.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0007] In a first aspect, a device discovery method is provided, comprising: in response to a first operation by a user, an electronic device scanning hotspot information of IoT devices within a communication range, the IoT devices within the communication range including a first IoT device, the hotspot information of the first IoT device including the SSID of the first IoT device; the AP hotspot of the first IoT device being always on, and the first IoT device not connected to the network; the electronic device displaying a first interface, the first interface including a target card, the target card being used to prompt the discovery of the first IoT device.

[0008] Based on the method provided in this application embodiment, there is no need to integrate an SDK into the first IoT device. The electronic device can scan for the first IoT device based on the AP hotspot that is always open on the first IoT device, and the first IoT device can be discovered without the first IoT device being connected to the network.

[0009] In one possible implementation, the electronic device displays the target card by: determining whether the SSID of a first IoT device exists in a first list, where the first list includes SSIDs of IoT devices that the electronic device has discovered and registered; if the SSID of the first IoT device does not exist in the first list, the electronic device displays the target card. It should be noted that since the AP hotspot of an IoT device is always on, the electronic device may repeatedly scan for the same IoT device and repeatedly prompt the user that the IoT device has been discovered. Based on the method provided in this application embodiment, the electronic device can determine whether the SSID of the currently discovered first IoT device exists in the first list. If it does not exist, it means that the currently discovered first IoT device is being discovered for the first time, and the user can be prompted about the first IoT device. This avoids the electronic device repeatedly discovering the same IoT device.

[0010] In one possible implementation, the method further includes: loading an H5 page (also known as an H5 interface) in response to a user's operation on the target card. The H5 page includes connection or management controls for IoT devices. This allows users to manage and control long-connected AP devices through the H5 page displayed on the electronic device.

[0011] In one possible implementation, the electronic device logs into the target account, and the first list includes the SSIDs of IoT devices that the electronic device has discovered and registered. This first list includes the SSIDs of multiple IoT devices discovered and registered by the electronic device logged into the target account. This avoids repeatedly prompting the user to discover the same IoT device when the same account is accessed.

[0012] In one possible implementation, before determining whether the SSID of the first IoT device exists in the first list, the method further includes: the electronic device requesting a second list from the cloud server, the second list including the SSIDs of at least one IoT device discovered and registered by multiple electronic devices logged into the target account; the electronic device receiving the second list from the cloud server and updating the first list based on the second list. That is, the electronic device can update the first list in a timely manner and determine whether the currently discovered IoT device (e.g., the first IoT device) has already been discovered and registered based on the updated first list, avoiding repeatedly prompting the user to discover the same IoT device.

[0013] In one possible implementation, the electronic device displaying the target card includes: the electronic device querying the initialization status, which indicates whether a second list has been acquired and the first list updated accordingly; if the electronic device acquires the second list and updates the first list accordingly, the initialization status is set to "initialized"; if the electronic device does not acquire the second list and does not update the first list accordingly, the initialization status is set to "uninitialized"; if the initialization status is "initialized," the target card is displayed; if the initialization status is "uninitialized," a scanning thread is started to scan the initialization status; if the scanning thread detects an initialization status of "initialized" before reaching a preset threshold, the scanning ends and the target card is displayed; if the scanning thread reaches the preset threshold, the scanning ends, the initialization status is marked as "initialized," and the target card is displayed. This avoids the problem of network latency preventing the electronic device from timely acquiring the latest second list from the cloud service, thus failing to determine whether the first IoT device has already been discovered and registered by a device with the same account, potentially leading to duplicate display of the first IoT device's target card (discovery pop-up).

[0014] In one possible implementation, the method further includes: the electronic device receiving a second operation from the user, the second operation being used to register the first IoT device with the cloud server, and the electronic device adding the SSID of the first IoT device to a first list. This allows the first list to be updated, thereby determining whether a currently discovered IoT device (e.g., the first IoT device) has already been discovered and registered, avoiding repeatedly prompting the user to discover the same IoT device (e.g., the first IoT device).

[0015] In one possible implementation, the method further includes: the electronic device receiving a third operation from a user, the third operation being used to delete the first IoT device, and the electronic device deleting the SSID of the first IoT device from the first list. That is, the first list can be updated promptly based on the user's deletion operation.

[0016] In one possible implementation, the method further includes: the electronic device receiving a device registration notification from the cloud server, the device registration notification including the SSID of a second IoT device; if the SSID of the second IoT device does not exist in the first list, the SSID of the second IoT device is added to the first list; or the electronic device receiving a device deletion notification from the cloud server, the device deletion notification including the SSID of a third IoT device; if the SSID of the third IoT device exists in the first list, the SSID of the third IoT device is deleted from the first list. This allows the first list to be updated promptly based on notifications from the cloud server, avoiding repeated notifications to the user about the discovery of the same IoT device (e.g., the first IoT device).

[0017] In one possible implementation, the first operation is a cold start operation of the first application, or the first operation is an operation on the first control in the second interface of the first application, the first control being used to add IoT devices.

[0018] In one possible implementation, the method further includes: if the SSID of the first IoT device exists in the first list, the target card is not displayed. If the SSID of the first IoT device exists in the first list, it means that the currently discovered first IoT device has already been discovered and registered, and there is no need to prompt the user about the first IoT device. This avoids the electronic device repeatedly prompting the user to discover the same IoT device.

[0019] In one possible implementation, the method further includes: saving the hotspot information of the first IoT device; and upon receiving an operation to connect to the first IoT device, connecting to the first IoT device's AP hotspot based on the saved hotspot information. In this way, the electronic device can automatically connect to the first IoT device's AP hotspot based on the saved hotspot information, without requiring manual user intervention.

[0020] In one possible implementation, the method further includes: after receiving a user's exit from the H5 page, verifying whether the SSID of the first IoT device matches the most recently successfully connected SSID; if the SSID of the first IoT device matches the most recently successfully connected SSID, disconnecting from the first IoT device. If the SSID of the first IoT device matches the most recently successfully connected SSID, it indicates that the currently connected SSID is the SSID of the first IoT device. Furthermore, since the user has exited the H5 page (the control interface of the first IoT device), it means the user no longer needs to control the first IoT device, so the connection between the electronic device and the first IoT device can be automatically disconnected without manual user operation (e.g., the user manually clicking the Wi-Fi hotspot icon in the status bar to turn off the hotspot of the IoT device connected to the phone). This avoids the problem of the phone still being connected to the first IoT device's AP hotspot after the user exits the control interface of the first IoT device, causing the phone to be unable to access the internet normally.

[0021] Secondly, a device discovery method is provided, applied to a system including an electronic device and a first IoT device, wherein the first IoT device's AP hotspot is always on and the first IoT device is not connected to the network. The method includes: the first IoT device broadcasting hotspot information of the first IoT device, the hotspot information of the first IoT device including the SSID of the first IoT device; in response to a first operation by a user, the electronic device scanning the hotspot information of IoT devices within its communication range, the IoT devices within the communication range including the first IoT device; the electronic device displaying a first interface, the first interface including a target card, the target card being used to prompt the discovery of the first IoT device.

[0022] Based on the method provided in this application embodiment, the AP hotspot of the first IoT device is always on, and the first IoT device is not connected to the network. The first IoT device can continuously broadcast its own hotspot information. Electronic devices can scan for the first IoT device based on the always-on AP hotspot of the first IoT device, without needing to integrate an SDK into the first IoT device or for the first IoT device to be connected to the network.

[0023] Thirdly, embodiments of this application provide an electronic device including a processor and a memory coupled together. The memory stores program instructions, which, when executed by the processor, cause the device to implement the method described in the first or second aspect and any possible design of the above.

[0024] Fourthly, this application provides a chip system including one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The aforementioned chip system can be applied to electronic devices including communication modules and memory. The interface circuits are used to receive signals from the memory of the electronic device and send the received signals to the processor, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device can perform the methods described in the first aspect or the second aspect and any possible design configuration thereof.

[0025] Fifthly, this application provides a computer-readable storage medium including computer instructions. When the computer instructions are executed on an electronic device (such as a mobile phone), they cause the electronic device to perform the methods described in the first aspect or the second aspect and any possible design configuration thereof.

[0026] Sixthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect or the second aspect and any possible design thereof.

[0027] In a seventh aspect, embodiments of this application provide an electronic device, which can be divided into different logical units or modules according to function, each unit or module performing different functions, so that the device performs the method described in the first aspect or the second aspect and any possible design method thereof.

[0028] Eighthly, embodiments of this application provide a communication system including an electronic device and a first Internet of Things (IoT) device. The first IoT device's access point (AP) hotspot is always on, and the first IoT device is not connected to the network. The electronic device and the first IoT device each perform certain steps, cooperating with each other to implement the method described in the first aspect or the second aspect and any possible design method thereof.

[0029] It is understood that the beneficial effects achieved by the electronic device described in the third aspect, the chip system described in the fourth aspect, the computer-readable storage medium described in the fifth aspect, the computer program product described in the sixth aspect, the electronic device described in the seventh aspect, and the system described in the eighth aspect can be referred to the beneficial effects in the first aspect and any possible design, which will not be repeated here. Attached Figure Description

[0030] Figure 1 A schematic diagram illustrating the connection between a mobile phone and an IoT device according to an embodiment of this application;

[0031] Figure 2 A schematic diagram of a system architecture provided for an embodiment of this application;

[0032] Figure 3A A schematic diagram of the software architecture of an electronic device and an IoT device provided in the embodiments of this application;

[0033] Figure 3B This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0034] Figure 3C This is a schematic diagram of the structure of an IoT device provided in an embodiment of this application;

[0035] Figure 4A A schematic diagram provided for an embodiment of this application;

[0036] Figure 4B This is yet another display schematic diagram provided for an embodiment of this application;

[0037] Figure 4C This is yet another display schematic diagram provided for an embodiment of this application;

[0038] Figure 4D This is yet another display schematic diagram provided for an embodiment of this application;

[0039] Figure 4E A connection diagram provided for an embodiment of this application;

[0040] Figure 4F This is yet another display schematic diagram provided for an embodiment of this application;

[0041] Figure 5A A schematic diagram of a device discovery process provided in an embodiment of this application;

[0042] Figure 5B A schematic diagram illustrating a device registration process provided in an embodiment of this application;

[0043] Figure 5C A schematic diagram illustrating a device connection and control process provided in an embodiment of this application;

[0044] Figure 5D A schematic diagram illustrating a device disconnection process provided in an embodiment of this application;

[0045] Figure 6A This application provides a schematic diagram of a process to avoid repeated discovery of IoT devices by electronic devices.

[0046] Figure 6B A flowchart illustrating an update of the ignore list provided in an embodiment of this application;

[0047] Figure 7 This application provides a schematic diagram of a process to avoid duplicate discovery of IoT devices by devices with the same account.

[0048] Figure 8 A flowchart illustrating a marking initialization state is provided for an embodiment of this application;

[0049] Figure 9 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0050] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the relevant concepts or technologies is given first:

[0051] In some related technologies, IoT device manufacturers can configure SDKs developed by electronics manufacturers into their IoT devices. IoT devices can then use capabilities such as Wi-Fi or BLE based on these SDKs to access the corresponding IoT ecosystem of the electronics manufacturer (e.g., the Honor ecosystem). For example, these IoT devices can be discovered and managed through the smart space application (APP) of the electronic device (e.g., a mobile phone).

[0052] For example, such as Figure 1 As shown in (a), taking a TV or speaker as an example of an IoT device, a TV manufacturer can configure an SDK developed by an electronics manufacturer (e.g., a mobile phone SDK) into the TV, and a speaker manufacturer can configure a mobile phone SDK into the speaker. The mobile phone can then control the TV based on the SDK integrated into the TV. For example, a user can remotely control the TV to turn it on and off, adjust the volume, and switch channels using their mobile phone. Similarly, a mobile phone can control the speaker based on the SDK integrated into the speaker. For example, a user can remotely control the speaker to turn it on and off, adjust the volume, and switch channels using their mobile phone.

[0053] However, for IoT device manufacturers, configuring the mobile SDK in IoT devices requires modifying the original firmware of the IoT devices, which increases workload and cost.

[0054] In other related technologies, electronic device manufacturers can configure SDKs developed by IoT vendors into their electronic devices. This allows the electronic devices to manage and control IoT devices based on their integrated SDKs.

[0055] For example, such as Figure 1 As shown in (b), taking an IoT device such as a TV or speaker as an example, electronic device manufacturers can configure the SDK developed by TV and / or speaker manufacturers in the mobile phone, and the mobile phone can control the TV and / or speaker based on its own integrated SDK.

[0056] However, different IoT devices may have different SDKs. In order to support more types of IoT devices, electronic devices need to integrate SDKs developed by multiple IoT manufacturers, resulting in a large amount of storage resources being consumed by electronic devices.

[0057] In some related technologies, mobile phone manufacturers and ecosystem partners can adapt according to standard protocols, such as BLE / Matter. Since different IoT devices may use different protocols, electronic devices need to store the protocol data of each IoT device for corresponding IoT communication. This places a significant burden on the storage and data processing capabilities of electronic devices.

[0058] This application provides a device discovery and management method that eliminates the need for SDK integration on the IoT device or electronic device side, and also eliminates the need to store protocol data. Electronic devices can discover IoT devices even when the IoT devices are not connected to the network, based on the IoT device's hotspot information. Furthermore, electronic devices can manage IoT devices through an extensible H5 page (i.e., an H5 page that can be customized according to business requirements), without increasing the cost of IoT devices or placing a significant burden on the storage and data processing capabilities of electronic devices.

[0059] H5 stands for Hypertext Markup Language 5.0. H5 pages can be embedded in applications on electronic devices (e.g., the Smart Space app). The Smart Space app can load the H5 page through a Uniform Resource Locator (URL) to access the services provided by the H5 page.

[0060] In this embodiment, IoT devices without integrated SDKs (e.g., mobile phone SDKs) can be referred to as shelf-mounted devices. Shelf-mounted devices can include different device types, such as personal devices (e.g., visual ear-cleaning devices, action cameras, camera glasses, dashcams, etc.) and home devices (e.g., televisions, projectors, air conditioners, etc.). The access type for shelf-mounted devices can be long-term AP access, meaning the AP hotspot of the shelf-mounted device is always on, allowing electronic devices to connect to and control the shelf-mounted device at any time based on its AP hotspot. In this embodiment, shelf-mounted devices with long-term AP access can be referred to as long-term AP connected devices. When electronic devices discover and manage long-term AP connected devices, it is not necessary to integrate the IoT device's SDK on the electronic device, nor is it necessary to configure the long-term AP connected device for network access. Electronic devices can discover long-term AP connected devices even when they are not connected to the network based on their hotspot information. Furthermore, electronic devices can manage long-term AP connected devices through an H5 page.

[0061] like Figure 2 As shown in the illustration, this application provides a communication system comprising an electronic device (e.g., a mobile phone), an IoT device (a long-connection AP device, such as a visual ear-cleaning device), and a cloud server. The electronic device (e.g., the mobile phone) does not integrate the SDK for the IoT device (e.g., the visual ear-cleaning device), and the IoT device (e.g., the visual ear-cleaning device) does not integrate the SDK for the electronic device (e.g., the mobile phone). The electronic device can discover long-connection AP devices even when they are not connected to the internet, based on the hotspot information of the long-connection AP devices. Furthermore, the electronic device can manage and control the long-connection AP devices through an H5 page. The electronic device can also register the device information of the IoT device with the cloud server.

[0062] like Figure 3AAs shown, electronic devices (e.g., mobile phones) may include IoT device management applications (e.g., smart space apps) and interconnection middleware. The IoT device management application and interconnection middleware may reside at the application layer. The smart space app may be an application built into the electronic device system or a downloaded third-party application; this embodiment does not impose such limitations. The smart space app may load H5 pages, through which it can control IoT devices (e.g., visual ear-cleaning devices) to play videos, take screenshots, save images (screenshots) to the phone's gallery, perform over-the-air (OTA) updates, and control the devices. The smart space app may also store device information (e.g., the SSID of the IoT device). The smart space app may also include a shelf-based control interface, through which it interacts with the interconnection middleware. The interconnection middleware may include a shelf-based module. The shelf-based module can perform operations such as device discovery, device network configuration, device connection, device control, and initialization status checks. The interconnection middleware may include a rack-mounted control interface, through which it can communicate with IoT devices, such as obtaining device information and sending control commands (i.e., controlling the IoT devices). IoT devices (e.g., a visual ear-collecting device) may include a video server. The video server can capture video streams. The image format of the video stream can be HTTP or MJPEG. The IoT device also includes a camera module (to implement photo-taking functionality). Optionally, the IoT device may also include a network configuration module. However, when the IoT device is a long-connection AP device, network configuration is not required; it connects to electronic devices based on the AP hotspot and receives control commands (operation commands) from electronic devices (e.g., the interconnection middleware).

[0063] Figure 3B This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application.

[0064] like Figure 3B As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0065] The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0066] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0067] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0068] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0069] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0070] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0071] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0072] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0073] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network.

[0074] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0075] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through audio devices (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194.

[0076] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0077] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0078] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0079] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD), a light-emitting diode (LED), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

[0080] Electronic device 100 can perform shooting functions through an ISP, camera 193, video codec, GPU, display screen 194, and application processor. The ISP processes data fed back from the camera 193. The camera 193 captures still images or video. The digital signal processor processes digital signals, including digital image signals and other digital signals. The video codec compresses or decompresses digital video. Electronic device 100 can support one or more video codecs. Thus, electronic device 100 can play or record video in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG 2, MPEG 3, MPEG 4, etc.

[0081] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0082] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Audio module 170 can also be used for audio signal encoding and decoding. Speaker 170A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. Receiver 170B, also called a "handset," is used to convert audio electrical signals into sound signals. Microphone 170C, also called a "microphone" or "microphone unit," is used to convert sound signals into electrical signals. Headphone jack 170D is used to connect wired headphones.

[0083] For example, electronic device 100 may be a mobile phone, smart remote control, handheld computer, augmented reality (AR) / virtual reality (VR) device, portable multimedia player (PMP), media player, etc. This application embodiment does not limit the specific type of electronic device.

[0084] like Figure 3C As shown, the IoT device 300 may include a wireless communication module 310, a processor 320, an internal memory 330, a power management module 340, a battery 350, a charging management module 360, an antenna 3, etc.

[0085] The processor 320 may include one or more processing units. For example, the processor 320 may include an access point (AP), a modem processor, a controller, a video codec, a DSP, etc.

[0086] In some embodiments, the processor 320 may include one or more interfaces. Interfaces may include I2C, I2S, PCM, UART, MIPI, GPIO, and / or USB interfaces, etc.

[0087] The wireless communication function of the IoT device 300 can be achieved through the antenna 3 and the wireless communication module 310. The wireless communication module 310 can provide wireless communication solutions for IoT devices 300, including WLAN (such as Wi-Fi networks), BT, and other wireless communication technologies.

[0088] Internal memory 330 can be used to store one or more computer programs, including instructions.

[0089] The power management module 340 is used to connect the battery 350, the charging management module 360, and the processor 320. The power management module 340 receives input from the battery 350 and / or the charging management module 360 ​​to power the processor 320, internal memory 330, and wireless communication module 310, etc. The charging management module 360 ​​receives charging input from a charger. The charger can be a wireless charger or a wired charger.

[0090] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the IoT device 300. In other embodiments of this application, the IoT device 300 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0091] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. In the description of this application, unless otherwise stated, "at least one" refers to one or more, and "more than one" refers to two or more. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences.

[0092] In this embodiment of the application, before an electronic device (e.g., a mobile phone) can control an IoT device (a long AP connected device), it needs to perform processes such as device discovery, device registration, and device connection.

[0093] To facilitate understanding, the following explanation uses a mobile phone as an example of an electronic device and an IoT device as a visual ear-collecting device to illustrate the user interface (UI) and user operations involved in the process of discovering, registering, connecting to, and controlling IoT devices.

[0094] For example, such as Figure 4A As shown in (a), the mobile phone can receive the user's action of clicking the Smart Space APP icon 402 on the desktop 401 (i.e., launching the Smart Space APP). In response to this action, as... Figure 4A As shown in (b), the mobile phone can display interface 403. Interface 403 may include control 404. In response to user actions on control 404 (e.g., a click action), such as Figure 4A As shown in (c), a pop-up window 405 can be displayed, which may include an option 406 for adding a device. In response to a user's action on the option 406 for adding a device (e.g., a click), as... Figure 4A As shown in (d) above, the mobile phone can display interface 407, which may include a prompt message 408 to inform the user that an IoT device scan is in progress. Additionally, interface 407 may also include options for manually adding and adding via QR code; the user can choose to add the IoT device manually or by scanning a QR code, which is not limited in this application.

[0095] When the mobile phone scans an IoT device (e.g., a visual ear cleaning device), such as Figure 4B As shown in (a), the mobile phone can display card 410. Card 410 may include the device name (e.g., visual ear cleaning device) and icon of the IoT device. Card 410 is used to prompt the user that the visual ear cleaning device has been discovered. In response to the user's action on card 410 (e.g., a click action), such as... Figure 4BAs shown in (b), the mobile phone can display interface 411. Interface 411 includes the name of the IoT device (i.e., the visual ear-cleaning device), the unique identifier corresponding to the IoT device (e.g., SN), and control 412. In response to the user's operation on control 412 (e.g., a click operation), as shown... Figure 4B As shown in (c), the mobile phone can display interface 413. Interface 413 may include prompt information 414 to inform the user of the device connection progress. After the connection is completed, as shown... Figure 4B As shown in (d), the mobile phone can display interface 415, which may include a notification message 416 to indicate to the user that the connection has been successful. Interface 415 may also include a return control 417. In response to a user's action on the return control 417 (e.g., a click), as shown... Figure 4C As shown in (a), the mobile phone can display interface 420. Interface 420 may include a card 421 corresponding to the visual ear-cleaning device. In some embodiments, interface 415 may automatically exit after displaying a preset duration (e.g., 3 seconds), and after exiting interface 415, the mobile phone can display interface 420.

[0096] Furthermore, in response to user actions on card 421, such as Figure 4C As shown in (b), the mobile phone can display interface 422, which may include control 423. In response to user actions on control 423 (e.g., a click action), such as... Figure 4C As shown in (c), a pop-up window 424 can be displayed. Pop-up window 424 can include a prompt message 425, which indicates that the current device (i.e., the visual ear-cleaning device) is to be used in conjunction with the Smart Space (APP). This means the visual ear-cleaning device is an IoT device without an integrated mobile SDK, and the H5 page loaded through the Smart Space APP is used to manage this IoT device. Pop-up window 424 can also include a prompt message 426, which includes the SSID of the current device (i.e., the visual ear-cleaning device), as well as the connection status (connected, saved) and internet access status (cannot access the internet). Pop-up window 424 can also include a cancel control 427 and a connect control 428. In response to the user's operation on the connect control 428, such as... Figure 4C As shown in (d), the mobile phone can display interface 430. Interface 430 may include a prompt message 431, which can indicate to the user that the connection is successful. The prompt message 431 may disappear after a preset duration (e.g., 1 second). Interface 430 may include control controls for the IoT device (i.e., the visual ear-cleaning device), such as a control 432 to start ear cleaning. It should be noted that when the mobile phone and the IoT device (i.e., the visual ear-cleaning device) are successfully connected, the Wi-Fi icon 433 in the status bar of interface 430 may change to indicate to the user that the mobile phone is currently connected to the AP hotspot of the IoT device and cannot access the Internet.

[0097] Furthermore, in response to user actions on the start ear cleaning control 432 (e.g., a click action), such as Figure 4D As shown, the mobile phone can display interface 440. Interface 440 may include control controls for multiple IoT devices (i.e., visual ear cleaning devices), such as brightness adjustment controls, image inversion controls, camera control, and angle controls.

[0098] It should be understood that after the IoT device successfully connects (i.e., registers successfully), in response to the user's operation on the card corresponding to the IoT device (e.g., card 421) (e.g., a click operation), the mobile phone can display the H5 page loaded by the Smart Space APP. For example, the H5 page may include, Figure 4C Interface 422 is shown in (b) of the diagram. Figure 4C Interface 430 shown in (d) and as shown in Figure 4D The interface shown is 440.

[0099] like Figure 4E As shown, when the mobile phone enters the ear-cleaning device card page (e.g., interface 440), the mobile phone can connect to the listening port of the visual ear-cleaning device. After successful connection, the mobile phone can send commands to the visual ear-cleaning device via Transmission Control Protocol (TCP) / User Datagram Protocol (UDP) or Hypertext Transfer Protocol (HTTP). The visual ear-cleaning device can send response messages or data back to the mobile phone, thereby achieving the effect of the mobile phone controlling the visual ear-cleaning device and displaying the image inside the ear (the video image inside the ear captured by the visual ear-cleaning device).

[0100] In some embodiments, when the smart space app is cold-started, it can silently scan for surrounding IoT devices (without requiring manual user-triggered scanning). If an IoT device (e.g., a visual ear-cleaning device) is detected, such as... Figure 4F As shown, the mobile phone can display card 450, which can be used to prompt the discovery of IoT devices (e.g., a visual ear cleaning device). Card 450 may also include cancel and connect controls. In response to the user's operation of the connect controls in card 450, the mobile phone can display as shown... Figure 4B The interface shown in (c) is as described above. Other operations can be found in the relevant descriptions above and will not be repeated here.

[0101] The specific implementation details of the processes of device discovery, device registration, device connection, and device disconnection are explained below.

[0102] like Figure 5AAs shown, the device discovery process includes:

[0103] 501. The IoT device is powered on and AP mode is enabled.

[0104] IoT devices could be, for example, visual ear cleaning devices. A visual ear cleaning device could include a power button, allowing users to power it on by pressing and holding the button, and then activate its AP mode (or, automatically activate AP mode after power-on) so that the device can be detected by a mobile phone.

[0105] The access point (AP) of the IoT device (the first IoT device) is always on, and the IoT device is not connected to the Internet (e.g., not connected to a router to access the Internet).

[0106] Understandably, in wireless access point (AP) mode, an IoT device acts as an access point for a hotspot network and can broadcast hotspot information. For example, this hotspot information may carry the IoT device's service set identifier (SSID) and basic service set identifier (BSSID). The SSID is the name of the hotspot network, and the BSSID is equivalent to the IoT device's MAC address. For example, the SSID of an IoT device (e.g., a visual ear-collecting device) could be bebird-xxxxx.

[0107] 502. The Smart Space APP receives the user's first operation.

[0108] The first operation could be launching (cold start) the Smart Space APP (for example, such as...). Figure 4A As shown in (a), the user clicks the Smart Space APP icon (402) on the desktop (401). Alternatively, the first operation could be adding a device (e.g., as shown in (a)). Figure 4A As shown in (c), the first operation can be a user clicking on option 406 to add a device.

[0109] 503. The Smart Space APP sends a device discovery request to the interconnect middleware.

[0110] After receiving the first operation, the Smart Space APP can send a device discovery request to the interconnection middleware. The device discovery request is used to request the interconnection middleware to listen for / scan for hotspot information sent by surrounding devices in order to discover nearby IoT devices.

[0111] 504. Interconnect middleware listens for / scans for hotspot information sent by surrounding devices.

[0112] In some embodiments, the first operation is when launching the Smart Space APP, such as... Figure 4A As shown in (b), when the mobile phone displays interface 403, the mobile phone can listen to the information broadcast around it through the Internet middleware, thereby discovering the hotspot network in the vicinity.

[0113] In other embodiments, when the first operation is the operation of adding a device, such as Figure 4A As shown in (d), during the mobile phone display interface 407, the interconnect middleware can listen to the information broadcast around it, thereby discovering the hotspot networks that exist around it.

[0114] 505. Interconnect middleware discovers IoT devices (e.g., visual ear-collecting devices).

[0115] Because IoT devices (e.g., visual ear-collecting devices) are constantly broadcasting hotspot information, the interconnect middleware can listen to the hotspot information broadcast by IoT devices, thereby discovering the IoT devices.

[0116] Interconnect middleware can obtain the BSSID and SSID of IoT devices from the hotspot information of IoT devices.

[0117] 506. The interconnected middleware sends device information of IoT devices to the smart space APP.

[0118] The interconnect middleware can match the SSID of an IoT device with product naming rules to obtain the device information. These product naming rules can be configured on the developer platform. Developers from electronic device manufacturers can obtain the product naming rules from the developer platform and configure them on the mobile phone.

[0119] The product naming convention can be based on the SSID to determine the product ID (prodid) and corresponding attribute information. It should be understood that different product IDs correspond to different attribute information. Attribute information may include the device name (also known as the default name), access method (e.g., AP hotspot access), and whether the device is a shelf-mounted device, etc.

[0120] For example, suppose the SSID of an IoT device is bebirdxxxxx. The prodid of an IoT device starting with bebird can be 0001. When the prodid is 0001, the device name is Visual Ear Collector; the access method is AP hotspot access; and the device belongs to the rack-mounted device category.

[0121] When an IoT device (e.g., a visual ear-cleaning device) is found to be a shelf-based device, the interconnect middleware can send a device discovery message to the smart space app. The device discovery message indicates the discovery of the IoT device and may include its device information. This information may include the SSID, device name (e.g., for a visual ear-cleaning device), and product serial number (SN). The SN can be uniquely identified by the interconnect middleware through hashing the scanned product ID (obtained from the developer platform based on the SSID) and BSSID.

[0122] 507. The Smart Space APP displays the first interface, which includes the target card.

[0123] In other embodiments, when the first operation is the operation of adding a device, such as Figure 4B As shown in (a), the first interface can be interface 407, and the target card can be card 410. Card 410 can be a card that pops up after the mobile phone actively scans the surrounding IoT devices.

[0124] In some embodiments, the first operation is when launching the Smart Space APP, such as... Figure 4F As shown, the first interface can be interface 403, and the target card can be card 450. Card 450 can be a card that pops up after the Smart Space APP silently scans the surrounding IoT devices (without requiring the user to actively trigger the scan) when it starts up.

[0125] The target card can also be called a target pop-up.

[0126] In this embodiment of the application, after the mobile phone discovers the IoT device, it can further register the IoT device with the cloud server.

[0127] like Figure 5B As shown, the device registration process includes:

[0128] 510. The Smart Space APP sends an authentication request to the interconnection middleware. The authentication request is used to request authentication of IoT devices.

[0129] In this embodiment, in response to a user's operation on the target card, the mobile phone can display a registration interface. The registration interface includes device information and connection controls for the IoT device. For example, such as... Figure 4BAs shown in (b), the registration interface can be interface 411. The device information of the IoT device may include the device name (e.g., visual ear-cleaning device) and SN (e.g., ca661a26f85c_ER...), and the connection control (also known as the registration control) can be control 412. After receiving the user's operation on control 412 (e.g., a click operation), the Smart Space APP can send an authentication request to the interconnection middleware.

[0130] In this embodiment of the application, the interconnection middleware can adopt an authentication-free process for IoT devices, enabling IoT devices to connect to mobile phones without authentication, thus allowing IoT devices to quickly connect to mobile phones.

[0131] 511. The interconnected middleware sends the authentication result to the Smart Space APP.

[0132] The authentication result could be, for example, successful authentication. Step 511 is optional; in the authentication-free process, the interconnected middleware may not need to send the authentication result to the Smart Space APP, and will assume successful authentication by default.

[0133] 512a. The Smart Space APP can request the Internet middleware to register IoT devices.

[0134] After authentication, the Smart Space APP can request the interconnection middleware to register the IoT device. Before registering the IoT device, the interconnection middleware can first apply for a registration ID from the cloud server, which means proceeding to step 512b.

[0135] 512b. The interconnect middleware sends a registration ID request to the cloud server.

[0136] The registration code request is used to request the cloud server to assign a registration ID to the Smart Space APP on the mobile phone. The registration ID request may include the mobile phone's device identifier and login account (the account used to log in to the Smart Space APP).

[0137] 513. The cloud server sends the registration ID and authentication code to the interconnect middleware.

[0138] After receiving a registration ID request, the cloud server can generate a registration ID (also known as a regID) based on the device identifier and login account. It's important to understand that each app on each device can have a different regID.

[0139] An authentication code (authcode) can be generated by a cloud server based on the device identifier, login account, and regID, and is used to authenticate electronic devices.

[0140] 514. The interconnect middleware sends its first random number (challenge) to the cloud server.

[0141] 515. The cloud server sends a second random number generated by the cloud server to the interconnect middleware.

[0142] 516. The interconnect middleware sends a registration request to the cloud server. The registration request includes the device information of the IoT device.

[0143] The registration request is used to request the registration of an IoT device (e.g., a visual ear cleaning device) on a cloud server. The device information for the IoT device may include SSID, device name (e.g., visual ear cleaning device), etc.

[0144] 517. The cloud server sends the IoT device's identifier (devid) and key (secret) to the interconnect middleware.

[0145] `devid` is a unique identity ID assigned by the cloud server to the IoT device. `secret` is the key used by the cloud server to interact with the interconnect middleware.

[0146] 518. The interconnected middleware sends a devid to the Smart Space APP.

[0147] 519. The Smart Space APP displays a successful connection interface.

[0148] After receiving the DEvid, the Smart Space APP confirms that the IoT device registration is complete and can display a successful connection message (registration completion screen). For example, the successful connection message (registration completion screen) can look like this: Figure 4B Interface 415 is shown in (d) of the diagram.

[0149] Furthermore, after the IoT device is registered, the mobile phone can connect to and control the IoT device.

[0150] like Figure 5C As shown, the device connection process includes:

[0151] 520. The Smart Space APP sends a device refresh request to the interconnect middleware.

[0152] For example, such as Figure 4C As shown in (a), after the Smart Space APP receives the user's operation on control 421 (e.g., click operation), it can send a device refresh request to the interconnect middleware.

[0153] The device refresh request is used to request a refresh of the local cached list of devices (second list).

[0154] 521. The interconnect middleware requests a list of devices from the cloud server.

[0155] After receiving a device refresh request from the Smart Space APP, the interconnect middleware can request a device list from the cloud server (i.e., pull a device list from the cloud server) and refresh the locally cached device list (the device list that was last requested from the cloud server) based on the device list obtained from the cloud server.

[0156] The device list (second list) includes device information (e.g., SSID, device name, etc.) for multiple IoT devices that have been discovered and registered by electronic devices. These multiple electronic devices are logged into the same account (target account) as the local device.

[0157] For example, the contents of the device list can be as shown in Table 1:

[0158] Table 1

[0159]

[0160] 522. The interconnect middleware receives the device list from the cloud server.

[0161] The cloud server sends a device list to the interconnect middleware, which then receives and saves the device list.

[0162] 523. The Smart Space APP sends a device connection request to the interconnection middleware.

[0163] For example, such as Figure 4C As shown in (b), after the Smart Space APP receives the user's operation on control 423 (e.g., click operation), it can send a device connection request to the interconnection middleware.

[0164] The device connection request includes the device information (deviceinfo) of the IoT device. The device information of the IoT device includes the connection type and device type of the IoT device.

[0165] 524. The interconnect middleware verifies the connection type and device type of IoT devices.

[0166] The connection type of an IoT device can be an AP connection (that is, an IoT device in AP mode allows electronic devices (as STAs) to access the device).

[0167] The purpose of the interconnect middleware to verify the connection type of IoT devices is to distinguish between IoT devices with the same name (e.g., the same SSID) but different connection types, or the same IoT device connected using different connection methods.

[0168] 525. If the interconnect middleware determines that the IoT device is a shelf-type device and the connection type is an AP connection, it saves the callback function.

[0169] When the interconnection middleware identifies the IoT device as a shelf-type device and the connection type as an AP connection, it can save the callback function registered by the Smart Space APP. The purpose of the callback function registered by the Smart Space APP is to return a result (connection successful) to the Smart Space APP after the interconnection middleware successfully connects to the IoT device.

[0170] 526. Interconnect middleware establishes network connections with IoT devices.

[0171] This refers to the AP hotspot that connects IoT devices via interconnect middleware.

[0172] In some embodiments, the interconnection middleware can store hotspot information of registered IoT devices. The interconnection middleware can automatically connect to the AP hotspot of the IoT devices based on the stored hotspot information, reducing manual operation.

[0173] 527. IoT devices return network connection results to the interconnection middleware.

[0174] The network connection result can be "network connection successful".

[0175] 528. The interconnect middleware stores the SSID of the IoT device as the name of the most recently successfully connected Wi-Fi network.

[0176] 529a. The interconnection middleware sends the connection result to the Smart Space APP.

[0177] The connection results include the Wi-Fi name (SSID) and Internet Protocol (IP) address of the visual ear-cleaning device, as well as the phone's current IP address. The IP address of the visual ear-cleaning device can also be referred to as the remote server address.

[0178] 529b. The Smart Space APP displays the connection results of IoT devices (e.g., connection successful).

[0179] 529c. The Smart Space APP loads an H5 page, which includes controls for connecting or managing IoT devices.

[0180] After the IoT device successfully connects (i.e., registers successfully), in response to the user's operation on the card corresponding to the IoT device (e.g., card 421) (e.g., a click operation), the mobile phone can display the H5 page loaded by the Smart Space APP. For example, the H5 page may include... Figure 4C Interface 422 is shown in (b) of the diagram. Figure 4C Interface 430 shown in (d) and as shown in Figure 4D The interface shown is 440.

[0181] 530. The Smart Space APP receives user operations on the management controls of IoT devices.

[0182] For example, such as Figure 4C As shown in (d), the user's operation on the management control of the IoT device can be a click operation on control 432.

[0183] 531. The Smart Space APP sends operation instructions to the interconnected middleware.

[0184] Operation commands could be, for example, commands to begin ear cleaning.

[0185] 532. Interconnect middleware sends operation instructions to IoT devices (e.g., instructions to start ear cleaning).

[0186] After receiving an operation command (such as a command to start ear cleaning), the IoT device can begin ear cleaning and return the ear cleaning screen to the mobile phone.

[0187] Based on the method provided in this application, electronic devices can manage and control IoT devices through an extensible H5 page. This eliminates the need to integrate an SDK on either the IoT device or the electronic device side, and also eliminates the need to store protocol data. It does not increase the cost of IoT devices, nor does it place a significant burden on the storage and data processing capabilities of electronic devices. Furthermore, it places no additional hardware requirements on IoT devices; only a Wi-Fi chip is required.

[0188] It should be noted that the AP hotspots of ordinary IoT devices (e.g., IoT devices integrating mobile SDKs) are typically used for discovery and network configuration, while the AP hotspots of the rack-mounted devices provided in this application embodiment are used not only for discovery but also for connection and control. The rack-mounted devices do not require network configuration, meaning they do not need to be connected to a specific Wi-Fi access point (e.g., a router). Electronic devices can access the AP hotspots of the rack-mounted devices and control them via an H5 page.

[0189] After an electronic device is connected to an IoT device, the device disconnection process can be executed (i.e., the connection between the electronic device and the IoT device is disconnected) under the following three circumstances. The three circumstances (circumstance 1, situation 2, and situation 3) are explained below.

[0190] like Figure 5D As shown, Case 1 includes steps 540-544:

[0191] 540. The Smart Space APP receives user requests to exit the card details page of the IoT device.

[0192] When users no longer need to manage IoT devices, they can exit the IoT device card details page (i.e., the H5 page, for example, interface 440).

[0193] 541. The Smart Space APP sends a request to the Interconnect Middleware to disconnect the IoT device.

[0194] The request to disconnect from an IoT device may include the IoT device's SSID.

[0195] 542. The interconnection middleware verifies whether the SSID carried in the request of the disconnected IoT device matches the SSID of the most recently successfully connected device.

[0196] The interconnect middleware can read the SSID of the most recently successfully connected device (i.e., the name of the most recently successfully connected Wi-Fi network) and determine whether the SSID carried in the request of the disconnected IoT device is the same as the SSID of the most recently successfully connected device.

[0197] 543. If the SSID carried in the request to disconnect from the IoT device matches the SSID of the most recently successfully connected device, disconnect the phone from the IoT device.

[0198] If the SSID carried in the request to disconnect from the IoT device matches the SSID of the most recently successfully connected device, it indicates that the currently connected SSID is the SSID of the IoT device. Furthermore, since the user has exited the IoT device's card details page (control interface, e.g., screen 440), it means the user no longer needs to control the IoT device. Therefore, the connection between the phone and the IoT device (including the connection between the interconnect middleware and the IoT device, and the connection between the phone's communication module and the IoT device) can be automatically disconnected without manual user intervention (e.g., the user manually clicking the Wi-Fi hotspot icon in the status bar to turn off the IoT device's hotspot). This avoids the problem of the phone remaining connected to the IoT device's AP hotspot after the user exits the IoT device's card details page, preventing the phone from accessing the internet normally.

[0199] 544. If the SSID carried in the request to disconnect from the IoT device does not match the SSID of the most recently successfully connected device, no operation will be performed.

[0200] If the SSID carried in the request to disconnect from the IoT device does not match the SSID of the most recently successfully connected device, it means that the SSID of the current connection is not the SSID of the IoT device. This is because the user may have manually switched the Wi-Fi hotspot in advance, that is, the user has disconnected the mobile phone from the IoT device in advance, so no operation is required.

[0201] Case 2 may include steps 545-548:

[0202] 545. The interconnect middleware detected that the IoT device has turned off AP mode.

[0203] 546. The interconnect middleware verifies whether the SSID of the IoT device with AP mode disabled matches the SSID of the most recently successfully connected device.

[0204] The interconnect middleware can read the SSID of the most recently successfully connected IoT device and determine whether the SSID of the IoT device with AP mode disabled is the same as the SSID of the most recently successfully connected IoT device.

[0205] 547. If the SSID of an IoT device in AP mode is matched with the SSID of the most recently successfully connected device, disconnect the phone from the IoT device.

[0206] If the SSID of an IoT device with AP mode disabled matches the SSID of the most recently successfully connected device, it means that the currently connected SSID is the SSID of the IoT device, and therefore the connection between the phone and the IoT device can be automatically disconnected.

[0207] 548. If the SSID of an IoT device in AP mode does not match the SSID of the most recently successfully connected device, no action will be taken.

[0208] If the SSID of the IoT device with AP mode disabled does not match the SSID of the most recently successfully connected device, it means that the currently connected SSID is not the SSID of the IoT device with AP mode disabled. It is possible that the currently connected device is the SSID of another IoT device. In this case, no action needs to be taken.

[0209] Case 3 may include steps 549-552:

[0210] 549. The interconnect middleware detected that the Wi-Fi network of the IoT device was disconnected.

[0211] In one possible scenario, a user might manually disconnect the Wi-Fi network from their IoT device. For example, a user could manually tap the Wi-Fi hotspot icon in the status bar to turn off the hotspot connected to the IoT device. In this case, the interconnect middleware will detect that the IoT device's Wi-Fi network has been disconnected.

[0212] 550. The interconnection middleware verifies whether the SSID of the disconnected Wi-Fi network matches the SSID of the most recently successfully connected network.

[0213] The interconnection middleware can read the SSID of the most recently successfully connected Wi-Fi network and determine whether the SSID of the disconnected Wi-Fi network is the same as the SSID of the most recently successfully connected network.

[0214] 551. If the SSID of the disconnected Wi-Fi network matches the SSID of the most recently successfully connected network, disconnect the phone from the IoT device.

[0215] If the SSID of the disconnected Wi-Fi network matches the SSID of the most recently successfully connected network, it means that the recently connected SSID is the SSID of the disconnected Wi-Fi network. Therefore, the connection between the phone and the IoT device can be disconnected. This avoids the problem of the phone still being connected to the IoT device's hotspot after the user exits the IoT device's card details page, causing the phone to be unable to access the internet normally.

[0216] 552. If the SSID of the disconnected Wi-Fi network does not match the SSID of the most recently successfully connected network, no action will be taken.

[0217] Furthermore, the inventors discovered in their research that since the AP hotspot of a long-connected AP device is always on, electronic devices may repeatedly scan for long-connected AP devices and repeatedly prompt the user that the long-connected AP device has been discovered, which will reduce the user experience.

[0218] This application provides a method for discovering devices, which can avoid electronic devices repeatedly prompting users to discover the long-connected AP device, thus improving the user experience. For example... Figure 6A As shown, the method includes:

[0219] 601a. ​​In response to the user's first action, the electronic device scans for hotspot information of IoT devices within its communication range.

[0220] The first step can be referred to in the relevant description of step 502, and will not be repeated here.

[0221] Electronic devices can scan for hotspot information of IoT devices within the communication range through interconnection middleware; for a related description, please refer to step 504.

[0222] The IoT devices within the communication range include a first IoT device, and the hotspot information of the first IoT device includes the SSID of the first IoT device. The first IoT device may be, for example, a visual ear-collecting device.

[0223] 601b: The electronic device scans the hotspot information of the first IoT device.

[0224] The hotspot information of the first IoT device may include the SSID.

[0225] Optionally, the first IoT device hotspot information may also include the BSSID.

[0226] 602. Determine if the SSID of the first IoT device exists in the ignore list.

[0227] The ignore list (first list) includes the SSIDs of IoT devices that have been discovered and registered by the electronic device.

[0228] 603. If the SSID of the first IoT device is not found in the list, the electronic device displays a target card, which is used to indicate that the first IoT device has been discovered.

[0229] The target card can be found in the description of step 507, which will not be repeated here.

[0230] If the SSID of the first IoT device is not found in the list, it means that the first IoT device has not been discovered or registered before. In this case, the target card can be displayed to prompt the user that the first IoT device has been discovered. That is, the target card will only be displayed to prompt the user that the first IoT device has been discovered if it is determined that the first IoT device has not been discovered or registered before. The electronic device can repeatedly prompt the user to discover the IoT device.

[0231] 604. If the SSID of the first IoT device in the list is ignored, the target card will not be displayed.

[0232] If the SSID of the first IoT device exists in the ignore list, it means that the first IoT device has already been discovered and registered. Therefore, the target card will not be displayed, avoiding repeated prompts to the user that the first IoT device has been discovered. In this way, the problem of electronic devices repeatedly prompting the user to discover IoT devices can be solved by using an ignore list.

[0233] It should be noted that the ignore list can be updated / refreshed in some cases. The following explains the process of updating / refreshing the ignore list. For example, ... Figure 6B As shown, an update / refresh of the ignore list can be triggered when any of steps 610-615 are performed.

[0234] 610. The interconnection middleware of electronic devices receives device registration notifications sent by the cloud server.

[0235] The device registration notification may include device information (e.g., the SSID of the IoT device) of the IoT device recently registered by the same account device (other devices that log in to the same target account (e.g., Honor account) as the electronic device).

[0236] In some embodiments, when a device logged into an account (e.g., a target account) registers a new IoT device (e.g., a second IoT device) with a cloud server, the cloud server can send the registered device information (e.g., the SSID of the second IoT device) to all online devices logged into that account. This allows all devices logged into the same account to be aware of the new IoT device registration, enabling each device to update its local ignore list based on the notification sent by the cloud server (e.g., adding the SSID of the newly registered IoT device (e.g., the second IoT device) to the ignore list).

[0237] 611. The interconnection middleware of the electronic device receives a device registration notification sent by the Smart Space APP.

[0238] In other words, the Smart Space APP requests the interconnection middleware to register the IoT device. The Smart Space APP can respond to the user's corresponding interface on the IoT device (such as...). Figure 4B The second operation of interface 411 shown in (b) (e.g., a click operation on control 412) requests the interconnect middleware to register the IoT device.

[0239] That is, when an electronic device discovers and registers a new IoT device, it can update its local ignore list (for example, by adding the SSID of the newly registered IoT device (e.g., the first IoT device) to the ignore list).

[0240] 612. The interconnection middleware of electronic devices receives a notification from the cloud server that a device has been deleted.

[0241] The device deletion notification may include device information (e.g., the SSID of the IoT device) of the IoT device recently deleted by the same account device (other devices logged into the same account as the electronic device (e.g., Honor account)).

[0242] In some embodiments, when a device logged into an account deletes a new IoT device (e.g., a third IoT device) from the cloud server, the cloud server can send the deleted device information (e.g., the SSID of the third IoT device) to all online devices logged into that account. This allows all devices logged into the same account to be aware that an IoT device has been deleted, and each device can update its local ignore list based on the notification sent by the cloud server (e.g., removing the SSID of the IoT device (e.g., the third IoT device) from the ignore list).

[0243] 613. The interconnection middleware of the electronic device receives a notification from the Smart Space APP to delete the device registration.

[0244] In other words, the Smart Space APP requests the interconnection middleware to delete the IoT device. The Smart Space APP can receive third-party operations from the user, which are used to delete the IoT device. In response to the user's operation to delete the IoT device, the APP requests the interconnection middleware to delete the IoT device.

[0245] In other words, when an electronic device deletes an IoT device, it can update its local ignore list (for example, by removing the IoT device's SSID from the ignore list).

[0246] 614. The interconnected middleware receives a device refresh request sent by the Smart Space APP.

[0247] After receiving a device refresh request from the Smart Space APP, the interconnect middleware can request a device list from the cloud server (i.e., pull a device list from the cloud server) and refresh the locally cached device list (the device list previously requested from the cloud server) based on the device list obtained from the cloud server. Furthermore, electronic devices can update their local ignore list based on the refreshed device list.

[0248] 615. The interconnect middleware receives the device list from the cloud server.

[0249] In some embodiments, when the Smart Space APP is cold-started, the interconnect middleware can request a list of devices from the cloud server.

[0250] In some embodiments, after the device list on the cloud server side is updated, the cloud server can proactively send the device list to the interconnect middleware of the electronic device. The electronic device can refresh its locally cached device list (the device list last requested from the cloud server) based on the device list obtained from the cloud server. Furthermore, the electronic device can update its local ignore list based on the refreshed device list.

[0251] After any of the steps 610-615 above, steps 616a-616b can be executed.

[0252] 616a. The interconnect middleware refreshes the local device list.

[0253] When the interconnect middleware of an electronic device receives an incremental message (e.g., a notification to register a device or a notification to delete a device), it can update the locally cached device list. For example, it can add the SSID of a newly registered IoT device to the device list based on a notification to register a device. Or, it can remove the SSID of an IoT device from the ignore list based on a notification to delete a device.

[0254] Once the interconnect middleware of electronic devices receives the full message (e.g., a new device list from a cloud server), it can overwrite the previously cached device list based on the new device list.

[0255] In this embodiment of the application, updating the local device list may include updating the device lists in memory and on the hard disk.

[0256] 616b, Interconnect middleware scans device lists and ignore lists.

[0257] The scan results include the following:

[0258] Scenario 1: The device list contains the SSID of IoT devices (shelf-mounted devices), while SSIDs of IoT devices (shelf-mounted devices) that are not in the list are ignored.

[0259] In this case, device registration is considered to have been triggered, including device registration notifications from the cloud server and the Smart Space APP. At this point, the SSID of the newly registered IoT device (shelf-mounted device) can be added to the ignore list.

[0260] When the scan result is case 1, steps 617-618 can be executed.

[0261] 617. The interconnect middleware adds the SSID of newly registered IoT devices to the ignore list in memory.

[0262] 618. Update the ignore list on the hard drive.

[0263] In this way, the next time the Smart Space APP is launched, it can determine whether the IoT device has been discovered and registered based on the updated ignore list in the hard drive, avoiding repeatedly prompting the user to discover the first IoT device.

[0264] Scenario 2: The device list contains the SSID of the IoT device, and the ignore list also contains the SSID of the IoT device.

[0265] In this case, it is assumed that the SSIDs of IoT devices in the device list have been added to the ignore list, and no action needs to be taken.

[0266] Scenario 3: If there is no SSID for an IoT device in the device list, ignore the SSID for an IoT device in the list.

[0267] In this case, it is assumed that the IoT device has been deleted, and steps 619-620 can be executed.

[0268] 619. The Interconnect Middleware removes the SSID of the newly deleted device from the ignore list in memory.

[0269] 620. Update the ignore list on the hard drive.

[0270] Case 4: If there is no SSID for an IoT device in the device list, ignore the SSID for which there is no IoT device in the list.

[0271] In this case, no action needs to be taken.

[0272] In some embodiments, multiple electronic devices are logged into the same account, such as mobile phone A and mobile phone B, both logged into the same account (e.g., a Honor account). Mobile phone A and mobile phone B may be devices belonging to the same user. Suppose a user discovers and registers an IoT device (e.g., a visual ear cleaning device) on mobile phone A. When mobile phone B cold-starts the Smart Space APP, it can request a device list from the cloud server (thus discovering the visual ear cleaning device registered on mobile phone A and adding its SSID to the local (mobile phone B) ignore list). However, if network latency occurs, mobile phone B may not be able to obtain the latest device list from the cloud service in a timely manner. Consequently, mobile phone B will not know that the visual ear cleaning device has already been discovered and registered by a device with the same account, and will repeatedly display the visual ear cleaning device discovery pop-up, affecting the user experience.

[0273] To avoid repeatedly prompting users about the discovery of IoT devices (shelf devices) for unregistered devices with the same account (e.g., phone B), such as... Figure 7 As shown, in Figure 6A Step 602 of the illustrated embodiment or Figure 5A Before step 506 in the illustrated embodiment, the following steps may also be performed:

[0274] 630. After an electronic device discovers an AP hotspot of an IoT device, it checks the initialization status.

[0275] After the interconnection middleware of electronic devices discovers the AP hotspot of IoT devices, it checks the initialization status.

[0276] The initialization status can be either initialized (initialization complete) or uninitialized (initialization incomplete). Initialized means that after a cold start, the Smart Space APP retrieves (pushes) the latest device list from the cloud server and updates the device list and ignore list locally; uninitialized means that after a cold start, the Smart Space APP does not retrieve the latest device list from the cloud server.

[0277] 631. If the initialization status is uninitialized, the interconnect middleware cache device discovers a message.

[0278] The device discovery message may include device information (e.g., SSID) of the discovered IoT devices.

[0279] 632. The interconnect middleware starts the scanning thread.

[0280] The scanning thread can be used to check the initialization status at regular intervals (e.g., 500ms).

[0281] 633a. The scanning thread performs one scan, that is, checks the initialization state.

[0282] The scanning thread can scan a preset number of times (e.g., 6 times).

[0283] 633b. After performing a scan, determine whether the initialization state is initialized.

[0284] 634. If the initialization state is uninitialized, determine whether the number of scans has reached the preset number (e.g., 6 times).

[0285] If the preset number of scans is not reached, the scan can be performed again.

[0286] 635. If after performing a scan, the initialization state is found to be initialized, the initialization state can be refreshed to initialized.

[0287] If the preset number of scans has not been reached, and the device is found to be in an initialized state, this state can be marked as initialized. That is, even before the preset number of scans has been reached, the electronic device has already obtained the latest device list from the cloud server and updated its local device list and ignore list. The updated ignore list includes the SSIDs of multiple IoT devices discovered and registered by the target account (e.g., a Honor account).

[0288] After step 635, step 636 can be executed.

[0289] 636. Determine if the SSID of the IoT device exists in the refreshed ignore list.

[0290] In some embodiments, if the scanning thread scans an initialization state that is already initialized (i.e., it has obtained the latest device list from the cloud server and updated the device list and ignore list locally) before reaching the preset number of scans, it can read the refreshed ignore list and determine whether the SSID in the device discovery message exists in the refreshed ignore list.

[0291] 637. If the number of scans has reached the preset number, the initialization status can be marked as initialized.

[0292] If the scanning thread scans a preset number of times (e.g., 6 times) and the initialization state is still uninitialized, the initialization state can be marked as initialized. In this case, the locally cached device list and ignore list are not updated.

[0293] 638. Determine if the SSID of the IoT device exists in the local cache's ignore list.

[0294] In other embodiments, if the initialization state remains uninitialized after a preset number of scans, the initialization state can be marked as initialized. The system then determines whether to report the device information of the currently discovered IoT devices to the Smart Space APP based on a locally cached ignore list. This avoids the problem of the scanning thread spending too much time scanning the initialization state, which could negatively impact the user experience.

[0295] After step 636 or step 638, steps 639-641 can be executed.

[0296] 639. If the SSID in the device discovery message does not exist in the ignore list, the interconnect middleware reports the device information of the currently discovered IoT device to the Smart Space APP.

[0297] If the SSID in the device discovery message does not exist in the refreshed ignore list, meaning that the currently discovered IoT device is a newly discovered IoT device (not discovered and registered by other devices under the same account), the interconnection middleware can report the device information of the currently discovered IoT device to the Smart Space APP. As a result, the Smart Space APP can display the card of the currently discovered IoT device, so that users can connect to and manage the IoT device through the target card.

[0298] If the SSID in the device discovery message does not exist in the local cached ignore list, the interconnect middleware can report the device information of the currently discovered IoT device to the Smart Space APP, so that the Smart Space APP can display the card of the currently discovered IoT device.

[0299] 640. The Smart Space APP displays the cards of the currently discovered IoT devices based on their device information.

[0300] Users can connect to and manage the IoT device through the target card.

[0301] 641. If the SSID in the device discovery message exists in the ignore list, the interconnect middleware may not report the device information of the currently discovered IoT device to the Smart Space APP, so the Smart Space APP will not display the card of the currently discovered IoT device.

[0302] If the SSID in the device discovery message exists in the refreshed ignore list or the local cached ignore list, meaning that the currently discovered IoT device is an IoT device that has already been discovered and registered by a device with the same account, then the interconnection middleware may not report the device information of the currently discovered IoT device to the Smart Space APP, and thus the Smart Space APP will not display the card of the currently discovered IoT device.

[0303] In this way, the device list on the local device is synchronized with the device list on the cloud service side. The local device can update the ignore list based on the synchronized device list, and then determine whether the currently discovered IoT device is a registered device based on the updated ignore list. If the currently discovered IoT device is a registered device, the user will not be prompted to discover the IoT device again. This can avoid the problem of repeatedly prompting the user to discover IoT devices (shelf devices) for the same account.

[0304] For example, such as Figure 8 As shown, the steps involved in initializing the state include:

[0305] 650. The Smart Space APP sends a device refresh request to the interconnect middleware.

[0306] 651. The interconnect middleware requests a list of devices from the cloud server.

[0307] Steps 650 and 651 can be referred to the relevant descriptions of steps 614 and 615 above, respectively, and will not be repeated here.

[0308] The initialization state can be marked as initialized under the following conditions.

[0309] Case 1: 652. The request for the device list failed due to network unavailability, incorrect parameters, or other reasons. The interconnect middleware is marked as initialized.

[0310] When the failure to request the device list is due to reasons such as network unreachability or incorrect parameters, the initialization state can be marked as initialized directly without starting the scanning thread, thus avoiding the scanning thread wasting time by scanning the initialization state meaninglessly.

[0311] Case 2: 653. If the scanning thread is already running, the interconnect middleware is marked as initialized.

[0312] After the scanning thread starts, the initialization status can be marked as initialized. For details, please refer to steps 635 and 637, which will not be repeated here.

[0313] In some embodiments, after the Smart Space APP is cold-started, the scanning thread is started only once and will not be started again after it has been started.

[0314] Case 3: 654. The interconnect middleware obtains the latest device list from the cloud server (i.e., the device list is successfully retrieved), and the interconnect middleware marks the initialization status as initialized.

[0315] In some embodiments, after the Smart Space APP has a cold start, or after the interconnection middleware receives a device refresh request from the Smart Space APP, it can request a device list from the cloud server. If the latest device list is obtained from the cloud server (i.e. the device list is successfully retrieved), the initialization status is directly marked as initialized.

[0316] In this way, the device list on the local device is synchronized with the device list on the cloud service side. The local device can update the ignore list based on the synchronized device list, and then determine whether the currently discovered IoT device is a registered device based on the updated ignore list. If the currently discovered IoT device is a registered device, the user will not be prompted to discover the IoT device again. This can avoid the problem of repeatedly prompting the user to discover IoT devices (shelf devices) for the same account.

[0317] This application also provides a chip system, such as... Figure 9 As shown, the chip system includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 are interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 902 can be used to send signals to other devices (e.g., the processor 901).

[0318] For example, interface circuit 902 can read instructions stored in the memory of an electronic device and send those instructions to processor 901. When the instructions are executed by processor 901, the electronic device (such as...) can... Figure 3B The electronic device 100 shown or the IoT device (such as...) Figure 3C The IoT device 300 shown executes the steps in the above embodiments.

[0319] Of course, the chip system may also include other discrete components, and this application embodiment does not specifically limit this.

[0320] This application also provides a computer-readable storage medium, which includes computer instructions that, when the computer instructions are used in an electronic device (such as...), Figure 3B The electronic device 100 shown or the IoT device (such as...) Figure 3CWhen the IoT device 300 shown is running, the electronic device 100 performs the various functions or steps performed by the electronic device (e.g., mobile phone) in the above method embodiment, and the IoT device 300 performs the various functions or steps performed by the IoT device (e.g., visual ear cleaning device) in the above method embodiment.

[0321] This application also provides a computer program product that, when run on a computer, causes the computer to perform various functions or steps performed by the electronic device in the above method embodiments.

[0322] This application also provides a processing device, which can be divided into different logical units or modules according to function. Each unit or module performs different functions, so that the processing device performs various functions or steps performed by electronic devices (e.g., mobile phones) or IoT devices (e.g., visual ear cleaning devices) in the above method embodiments.

[0323] Through the above description of the embodiments, those skilled in the art can clearly understand that the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0324] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0325] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0326] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0327] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0328] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A device discovery method, characterized in that, include: In response to the user's first operation, the electronic device scans the hotspot information of IoT devices within the communication range. The IoT devices within the communication range include a first IoT device, and the hotspot information of the first IoT device includes the SSID of the first IoT device. The AP hotspot of the first IoT device is always on, and the first IoT device is not connected to the network. The electronic device displays a first interface, which includes a target card used to prompt the discovery of the Internet of Things (IoT) device.

2. The method according to claim 1, characterized in that, The electronic device displays the target card, including: The electronic device determines whether the SSID of the first IoT device exists in the first list, wherein the first list includes the SSIDs of IoT devices that the electronic device has discovered and registered; If the SSID of the first IoT device does not exist in the first list, the electronic device displays the target card.

3. The method according to claim 1 or 2, characterized in that, The method further includes: In response to the user's operation on the target card, an H5 page is loaded, the H5 page including management controls for the first IoT device.

4. The method according to claim 2, characterized in that, The electronic device logs into the target account, and the first list includes the SSIDs of IoT devices that the electronic device has discovered and registered, including: The first list includes the SSIDs of IoT devices that have been discovered and registered by multiple electronic devices logged into the target account.

5. The method according to claim 4, characterized in that, Before determining whether the SSID of the first IoT device exists in the first list, the method further includes: The electronic device requests a second list from the cloud server, the second list including the SSID of at least one IoT device discovered and registered by multiple electronic devices logged into the target account; The electronic device receives the second list from the cloud server and updates the first list based on the second list.

6. The method according to claim 5, characterized in that, The electronic device displays the target card, including: The electronic device queries the initialization status, which indicates whether the second list is acquired and the first list is updated based on the second list. If the electronic device acquires the second list and updates the first list based on the second list, the initialization status is initialized. If the electronic device does not acquire the second list and does not update the first list based on the second list, the initialization status is uninitialized. If the initialization status is initialized, the target card is displayed; If the initialization state is uninitialized, start the scanning thread to scan the initialization state; If the scanning thread reaches the preset threshold number of scans before the initialization state is initialized, the scan ends and the target card is displayed. If the number of scans by the scanning thread reaches a preset threshold, the scanning ends, the initialization status is marked as initialized, and the target card is displayed.

7. The method according to any one of claims 2-6, characterized in that, The method further includes: The electronic device receives a second operation from the user, the second operation being used to register the first IoT device with the cloud server, and the electronic device adds the SSID of the first IoT device to the first list.

8. The method according to any one of claims 2-7, characterized in that, The method further includes: The electronic device receives a third operation from the user, the third operation being used to delete the first IoT device, and the electronic device deleting the SSID of the first IoT device from the first list.

9. The method according to any one of claims 2-8, characterized in that, The method further includes: The electronic device receives a device registration notification from the cloud server. The device registration notification includes the SSID of the second IoT device. If the SSID of the second IoT device does not exist in the first list, the SSID of the second IoT device is added to the first list; or... The electronic device receives a device deletion notification from the cloud server. The device deletion notification includes the SSID of the third IoT device. If the SSID of the third IoT device exists in the first list, the SSID of the third IoT device is deleted from the first list.

10. The method according to any one of claims 1-9, characterized in that, The first operation is a cold start operation of the first application, or the first operation is an operation on the first control in the second interface of the first application, the first control being used to add IoT devices.

11. The method according to claim 2, characterized in that, The method further includes: If the SSID of the first IoT device exists in the first list, the target card will not be displayed.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: Save the hotspot information of the first IoT device; Upon receiving the operation to connect to the first IoT device, the system connects to the AP hotspot of the first IoT device based on the saved hotspot information.

13. The method according to claim 3, characterized in that, The method further includes: Upon receiving a user's exit from the H5 page, the system verifies whether the SSID of the first IoT device matches the SSID of the most recently successfully connected device. If the SSID of the first IoT device matches the SSID of the most recently successfully connected device, the system disconnects the connection with the first IoT device.

14. A device discovery method, characterized in that, A method applicable to a system including electronic devices and a first IoT device, wherein the first IoT device's AP hotspot is always on and the first IoT device is not connected to the network, the method comprising: The first IoT device broadcasts the hotspot information of the first IoT device, and the hotspot information of the first IoT device includes the SSID of the first IoT device; In response to the user's first operation, the electronic device scans hotspot information of IoT devices within its communication range, including the first IoT device. The electronic device displays a first interface, which includes a target card used to indicate the discovery of the first IoT device.

15. A communication system, characterized in that, The device includes an electronic device and a first Internet of Things (IoT) device, wherein the first IoT device's access point (AP) hotspot is always on and the first IoT device is not connected to the Internet, and the electronic device and the first IoT device perform the method as described in claim 14.

16. An electronic device, characterized in that, The electronic device includes: a wireless communication module, a memory, and one or more processors; the wireless communication module, the memory, and the processor are coupled together. The memory is used to store computer program code, which includes computer instructions; when the computer instructions are executed by the processor, the electronic device performs the method as described in any one of claims 1-14.

17. A computer-readable storage medium, characterized in that, Includes computer instructions; When the computer instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-14.

Images