Gateway, sub-device and interaction method of gateway and sub-device

Abstract

The invention provides a gateway and a sub-device and an interaction method of the gateway and the sub-device. The gateway and the sub-device comprise the gateway, the sub-device, a mobile device and a server. The gateway and sub-device interaction method is applied to a gateway and comprises the steps that the gateway is connected with a mobile device through Bluetooth to obtain network configuration data, and the gateway is connected to the Internet according to the network configuration data; the gateway is connected with the sub-device through Bluetooth; judging whether the gateway can be connected to the mobile equipment through the Internet; in response to the gateway being unable to connect to the mobile device over the Internet, the gateway is Bluetooth-connected with the mobile device while maintaining Bluetooth connection with the sub-device. According to the embodiment of the invention, when the sub-device cannot be directly connected with the network, the gateway can be in Bluetooth connection with the mobile device while keeping in Bluetooth connection with the sub-device, so that a user can still control the sub-device through the gateway under the condition that the Internet cannot be connected, the use requirement of the user is met, and the use experience of the user is improved.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) technology, and specifically relates to a method for interaction between a gateway and sub-devices. Background Technology

[0002] Currently, when a sub-device cannot directly connect to the network, the remote control link between the user's mobile device and the sub-device will be interrupted, preventing the user from remotely controlling the sub-device through the mobile device, failing to meet the user's remote use needs, and reducing the user experience. Summary of the Invention

[0003] To address the aforementioned problems, the primary objective of this invention is to provide a method for interaction between a gateway and its sub-devices, thereby resolving the technical issues.

[0004] To achieve the above objectives, the technical solution of the present invention is as follows:

[0005] This invention provides a gateway and a sub-device, comprising:

[0006] The gateway connects to mobile devices via Bluetooth. The gateway obtains network configuration data from the mobile devices to enable the gateway to connect to the Internet.

[0007] The sub-device connects to the gateway via Bluetooth. The sub-device is an electronic device in a smart home scenario that requires connectivity but cannot directly connect to the internet. In this scenario, the sub-device in this application can be a door lock of a specific model.

[0008] Mobile devices connect to the internet and then connect to a gateway to control the operational status of sub-devices. The mobile devices have an application installed that can interact with the gateway.

[0009] The server is connected to the Internet, and the server connects to mobile devices and a gateway via the Internet, enabling mobile devices to control the gateway to download and upgrade data from the server.

[0010] This invention provides a method for interaction between a gateway and its sub-devices, applied to a gateway, the method comprising:

[0011] Step S1: The gateway connects to the mobile device via Bluetooth to obtain network configuration data, and then connects to the Internet based on the network configuration data.

[0012] Mobile devices include electronic devices such as mobile phones, laptops, and tablets.

[0013] Step S2: The gateway connects to the sub-device via Bluetooth.

[0014] The sub-devices can be electronic devices or wearable devices used in the smart home field, such as refrigerators and speakers. In this scenario, the sub-device can be a door lock.

[0015] Step S3: Determine whether the gateway can connect to the mobile device via the Internet.

[0016] Step S4: In response to the gateway's inability to connect to the mobile device via the Internet, the gateway establishes a Bluetooth connection with the mobile device while maintaining a Bluetooth connection with the sub-device.

[0017] Compared with the prior art, the beneficial effects of this application are as follows: When encountering situations where the sub-device cannot directly connect to the network, the gateway can maintain a Bluetooth connection with the sub-device while also connecting to the mobile device via Bluetooth. This allows users to control the sub-device through the gateway even when the Internet is unavailable, thus meeting user needs and improving the user experience.

[0018] Step S1: The gateway connects to the mobile device via Bluetooth to obtain network configuration data. Based on this network configuration data, the gateway connects to the Internet, including:

[0019] Step S11: The gateway sends the first BLE broadcast to connect to the mobile device via BLE. The mobile device has an application installed that can interact with the gateway.

[0020] After the gateway is powered on, it automatically enters network configuration mode and broadcasts its identification information via BLE. The application controls mobile devices to search for the first BLE broadcast, establishes a BLE connection with the gateway, obtains the gateway's identification information, sends the gateway's identification information to the server, and requests registration.

[0021] The gateway is equipped with an indicator light that flashes rapidly when the gateway enters the network configuration mode. Preferably, the indicator light flashes twice per second.

[0022] The gateway's identification information includes the gateway's DID (Device Identifier), X-API-Key, vendor, and PID (Product ID). The DID is a string or code used to uniquely identify the gateway device, distinguishing different gateways within the network and enabling functions such as device management, data traceability, and communication authentication. In this embodiment, the gateway's BLE MAC address is used as the DID.

[0023] BLE (Bluetooth Low Energy) is a wireless technology standard designed for low-power, short-range wireless communication and is widely used in the Internet of Things, wearable devices, smart homes and other fields.

[0024] Step 12: The gateway obtains and parses network configuration data from the mobile device, and connects to the Internet based on the parsed network configuration data.

[0025] Users input network configuration data into an application on their mobile devices. The application controls the mobile device to send the network configuration data to the gateway via a BLE connection. The gateway retrieves and parses the network configuration data from the mobile device, connects to the corresponding router, and thus connects to the internet. The network configuration data includes the Wi-Fi name and password.

[0026] When the gateway is connected to the network, the indicator light flashes slowly. Preferably, the indicator light flashes slowly once every 2 seconds.

[0027] Step S13: Determine whether the gateway is connected to the Internet.

[0028] Step S14: In response to the gateway connecting to the Internet, the gateway uploads version data to the server via the Internet, receives MQTT topics sent by the server via the Internet, and subscribes to MQTT topics.

[0029] Preferably, the gateway receives the MQTT topic and token sent by the server via the Internet.

[0030] In this context, a token is a temporary credential used in a computer system to identify identity, permissions, or status. It is typically generated by the server and returned to the gateway. Subsequent requests from the gateway must include this token to verify its legitimacy.

[0031] Version data includes the current firmware version number of the gateway. Firmware is a special type of software that is directly burned into the gateway's read-only memory (ROM), flash memory, or electrically erasable programmable read-only memory (EEPROM). It provides the hardware with an initialization instruction set, ensuring that the gateway can start correctly and perform basic operations after power-on.

[0032] MQTT (Message Queuing Telemetry Transport) topics are paths in the MQTT protocol used to identify message publishing and subscription.

[0033] Step S15: In response to the gateway not being connected to the Internet, the gateway sends network configuration failure data to the mobile device via the BLE connection.

[0034] The gateway sends network configuration failure data to the mobile device via BLE connection, and the mobile device's application displays "Network configuration failed".

[0035] When the gateway is not connected to the Internet, the gateway indicator light will continue to flash; the light will turn off once the connection is successful.

[0036] Step S2, the gateway connects to the sub-device via Bluetooth, including:

[0037] Step S21: The gateway sends a second BLE broadcast to perform a BLE scan and search for BLE broadcasts from nearby sub-devices.

[0038] Step S22: The gateway establishes a BLE connection with the sub-device, performs authentication through a preset protocol, and establishes a communication session between the gateway and the sub-device.

[0039] The communication session can be a MW session, which is related to the interface of the mobile core network.

[0040] Step S23: The gateway receives the sub-device's identity data through a communication session and sends the sub-device's identity data to the server via the Internet to request registration.

[0041] The identification data of the sub-device includes information such as the sub-device's DID, on / off status, and power level.

[0042] Step S24: The gateway receives MQTT topics sent by the server via the Internet, subscribes to MQTT topics, and records the binding information of sub-devices.

[0043] After the gateway completes this step, the server sends "Sub-device registration successful" data to the mobile device and synchronizes the current sub-device status. The application installed on the mobile device displays "Added successfully".

[0044] The gateway records the binding information of the sub-devices to support subsequent communication.

[0045] Step S4: The gateway establishes a Bluetooth connection with the mobile device while maintaining the Bluetooth connection with the sub-device, including:

[0046] Step S41: The gateway sends a third BLE broadcast at the same time as sending the second BLE broadcast;

[0047] After the gateway starts up, it maintains two sets of broadcasts simultaneously. The second BLE broadcast sends signals for interaction with sub-devices according to the original mechanism. These signals include information such as device identifier and connection status. The third BLE broadcast is used for emergency communication with mobile devices, sending signals containing an emergency identifier to the mobile devices. The field format of this signal is: Emergency Identifier + Device ID.

[0048] Preferably, the sending rules for the second and third BLE broadcasts are as follows: if the gateway hardware supports parallel sending, they are started simultaneously; if not, the second BLE broadcast is sent first, and the third BLE broadcast is inserted every 500ms.

[0049] Preferably, the dynamic switching mechanism between the second and third BLE broadcasts is as follows: when the gateway maintains a connection with the sub-device, both broadcasts are continuously sent; if the connection between the gateway and the sub-device is interrupted, the third BLE broadcast is immediately stopped, only the second BLE broadcast is sent, and an attempt is made to reconnect to the sub-device; after a successful reconnection, the sending of the third BLE broadcast is resumed.

[0050] Step S42: The gateway establishes a BLE connection with the mobile device through a third BLE broadcast, generates verification data, and sends the verification data to the mobile device. The verification data includes a first verification string and a sub-device status string.

[0051] In this embodiment, the gateway stores the first verification string locally.

[0052] Preferably, the verification data also includes an empty string, which is used to pad the length of the verification data to meet the requirements of the encryption algorithm. That is, the verification data consists of a first verification string, a sub-device status string, and an empty string. The first verification string can be a 6-character random string.

[0053] In some implementations, the encryption algorithm limits the string length of the verification data to 16 bits, and an empty string is used to pad the string length of the verification data to 16 bits.

[0054] Step S43: The gateway and mobile device perform encrypted transmission.

[0055] The mobile device receives and stores the verification data, and the application installed on the mobile device sends a message indicating "Connection successful".

[0056] For details on the encrypted transmission process, please refer to steps S431-S436.

[0057] Step S43, the gateway and mobile device perform encrypted transmission, including:

[0058] Step S431: The gateway receives the encryption command sent by the mobile device and decrypts the encryption command using a preset key to obtain a decryption string, which includes a second verification string and a command string.

[0059] The mobile device concatenates the control command with a second verification string obtained through verification data to obtain the command to be encrypted. Preferably, the command to be encrypted may also include an empty string, which is used to pad the length of the command to meet the requirements of the encryption algorithm. That is, the command to be encrypted consists of a second verification string, a control command, and an empty string. The second verification string can be a 6-character random string.

[0060] Preferably, the mobile device can use AES ECB 128bit to encrypt the command to be encrypted, obtain the encrypted command, and send the encrypted command to the gateway.

[0061] The gateway receives encrypted commands sent by mobile devices and decrypts them using a preset key to obtain a decrypted string. The preset key can be in the format: M_lj_[last 8 bits of the gateway's MAC address], for example, M_lj_32ac3373.

[0062] Step S432: The gateway verifies whether the second verification string in the decryption string is consistent with the first verification string.

[0063] Step S433: In response to the second verification string in the decryption string being consistent with the first verification string, the gateway sends the instruction corresponding to the instruction string to the sub-device.

[0064] Step S434: The gateway updates the first verification string in the verification data and obtains the status of the sub-device to update the sub-device status string in the verification data.

[0065] When the status of a sub-device changes, the gateway synchronously updates the sub-device status string.

[0066] Step S435: The gateway sends the updated sub-device status string to the mobile device.

[0067] When the status of a sub-device changes, the gateway synchronously updates the sub-device status string and sends the updated sub-device status string to the mobile device.

[0068] Step S436: In response to the discrepancy between the second verification string and the first verification string in the decryption string, the gateway updates the first verification string in the verification data and sends an instruction to the mobile device to invalidate data.

[0069] Regardless of whether the second verification string in the decryption string is the same as the first verification string, the gateway randomly generates a new first verification string.

[0070] Step S42: The gateway establishes a BLE connection with the mobile device via a third BLE broadcast, generates authentication data, and sends the authentication data to the mobile device, followed by:

[0071] Step S421: Determine whether the BLE connection established between the gateway and the mobile device is interrupted.

[0072] Step S422: In response to the interruption of the BLE connection established between the gateway and the mobile device, the gateway saves the current data and determines whether the gateway will establish a BLE connection with the mobile device within a preset time.

[0073] Preferably, the preset time can be 30 seconds.

[0074] Step S423: In response to the gateway failing to establish a BLE connection with the mobile device within a preset time, the gateway clears the current data and sends a third BLE broadcast.

[0075] After the gateway connects to the internet and connects to the sub-devices via Bluetooth, users can initiate requests such as "Turn sub-device on / off," "Delete sub-device," "Delete gateway," and "Upgrade request" through the application installed on their mobile devices. The specific workflow of the gateway in each request is as follows:

[0076] When a user initiates an "on / off sub-device" request on an application installed on a mobile device, the gateway's workflow is as follows:

[0077] Step S51: The gateway receives the switch command for the sub-device sent by the server through the MQTT topic, parses the switch command for the sub-device, and sends the target command to the sub-device.

[0078] Users send "on / off sub-device" requests to the server through applications installed on their mobile devices, and the server sends the sub-device on / off instructions to the gateway via an MQTT topic.

[0079] Step S52: The gateway receives the current status data sent by the sub-device through the BLE connection, and then synchronizes the current status data to the server.

[0080] After the sub-device executes the command, it sends its current status data (such as "on" or "off") to the gateway via the BLE connection. The gateway then synchronizes the current status data to the server, which in turn pushes it to the application installed on the mobile device. The application updates and displays the sub-device's status. If the sub-device fails to execute the command (e.g., the BLE connection is interrupted), the gateway reports an error to the server, and the application installed on the mobile device displays "Operation failed."

[0081] When a user initiates a "Delete Sub-device" request on an application installed on a mobile device, the gateway's workflow is as follows:

[0082] Step S61: The gateway receives the delete sub-device instruction via MQTT topic.

[0083] The user sends a "delete sub-device" request to the server through an application installed on their mobile device. The application controls the mobile device to send the sub-device's DID to the server. The server then sends the delete sub-device command to the gateway via an MQTT topic.

[0084] Step S62: The gateway clears the binding information of the sub-device and disconnects the BLE connection with the sub-device;

[0085] Preferably, after the gateway completes this step, it needs to be restarted to complete the instruction to delete the sub-device. The server sends a notification "Sub-device has been deleted" to the application installed on the mobile device.

[0086] When a user initiates a "Remove Gateway" request on an application installed on a mobile device, the gateway's workflow is as follows:

[0087] Step S71: The gateway receives the delete gateway command via the MQTT topic.

[0088] The user sends a "delete gateway" request to the server through an application installed on their mobile device. The mobile device then sends the gateway's DID to the server. The server then sends a delete gateway command to the gateway via an MQTT topic.

[0089] Step S72: The gateway clears the network configuration data and disconnects from the server.

[0090] Network configuration data includes Wi-Fi network configuration data. The indicator light on the gateway resumes fast flashing, indicating that the network configuration mode has been entered. Preferably, the server sends a notification "Gateway has been deleted" to the application installed on the mobile device.

[0091] When the server detects a new version of the gateway firmware, or when a user initiates an "upgrade request" on an application installed on a mobile device, the gateway's workflow is as follows:

[0092] Step S81: The gateway receives the upgrade command sent by the server through the MQTT topic, and downloads the upgrade data from the server through an HTTPS request.

[0093] Users send an "upgrade request" to the server through an application installed on their mobile devices. The server then sends an upgrade command to the gateway via an MQTT topic. The gateway downloads the upgrade data from the server via an HTTPS request.

[0094] The upgrade instructions include OTA (Over-the-Air Technology) instructions. Preferably, the OTA instructions include the firmware version and a download link. OTA is a technology that uses wireless communication networks (such as mobile networks, Bluetooth, etc.) to remotely update the software, manage the configuration, or transmit data to a gateway.

[0095] HTTPS (Hypertext Transfer Protocol Secure) is a secure data transmission protocol that adds an SSL / TLS (Secure Sockets Layer / Transport Layer Security) protocol layer to HTTP to ensure that data is encrypted and protected during transmission between the client and the server.

[0096] Upgrade data may include upgrading the gateway's firmware. Firmware is a special type of software that is directly burned into the gateway's read-only memory (ROM), flash memory, or electrically erasable programmable read-only memory (EEPROM). It provides the hardware with an initialization instruction set, ensuring that the gateway can start correctly and perform basic operations after power-on.

[0097] Step S82: The gateway verifies whether the upgrade data is complete.

[0098] Preferably, CRC detection technology can be used to verify whether the upgrade data is complete. CRC (Cyclic Redundancy Check) is an error detection technology widely used in data communication and storage. It verifies whether errors have occurred in the data during transmission or storage by calculating the check value of the data.

[0099] Step S83: In response to the completeness of the upgrade data downloaded by the gateway, the gateway installs the upgrade data, automatically restarts after installation, and reports the current version data to the server.

[0100] The gateway incorporates flash memory and features indicator lights. When installing upgrade data, the gateway writes the upgrade data to the flash memory. During the upgrade process, the indicator lights flash rapidly, and the gateway automatically restarts upon completion. Preferably, the indicator lights flash twice per second.

[0101] The version data includes the firmware version number of the newly installed firmware.

[0102] Step S84: In response to the incomplete upgrade data downloaded by the gateway, the gateway reports an error to the server.

[0103] If the gateway detects that the upgrade data downloaded is incomplete, the gateway will revert to the original version, the indicator light will flash slowly, and the gateway will restart. After restarting, the indicator light will turn off.

[0104] When a user manually operates a sub-device, the gateway's workflow is as follows:

[0105] Step S91: The gateway receives the current status data sent by the sub-device via the BLE connection.

[0106] After detecting manual operation, the sub-device updates its current operating status and sends the current status data to the gateway.

[0107] Step S92: The gateway sends the current status data to the server via an MQTT topic.

[0108] Preferably, after the gateway completes this step, the server sends the current status data to the mobile device, and the application installed on the mobile device displays the current status of the sub-device in real time.

[0109] To ensure secure communication between the gateway and sub-devices, and between the gateway and the server, and to prevent data from being tampered with or eavesdropped on, transmitted commands (such as "turn sub-device on / off", "delete sub-device", "delete gateway", "upgrade request") and status information (such as the status of sub-devices) must be encrypted.

[0110] Regarding the choice of encryption algorithm: based on the hardware support of the gateway (using the Nordic52840 chip, which contains a 128-bit AES-128-CCM / ECB encryption module), the AES-128-CCM algorithm is selected for encryption, which balances encryption and integrity verification.

[0111] Regarding key management:

[0112] Gateway and server keys: During registration, the server generates a random 128-bit key, which is sent to the gateway through an encrypted channel (such as HTTPS) and stored in the built-in FLASH.

[0113] Gateway and lock keys: There is no key-related mechanism in the interaction between the gateway and the lock. After establishing a connection via BLE, the two only initiate interaction through a "session start request" command. Preferably, this command adopts an "unencrypted" and "unsigned" strategy, and the interaction between the gateway and the lock relies on fixed command codes and data format verification to achieve basic control.

[0114] Regarding the encryption process:

[0115] Data processing by the sender: The sender (gateway or lock) encapsulates data in a fixed format of "frame header (HEAD) + data segment (DATA)". The frame header contains control information such as instruction type and instruction code, and the data segment contains specific business data (such as lock status, registration information, etc.). The entire process involves no encryption; data is transmitted in plaintext, and the encapsulation format does not include data length or checksum fields.

[0116] Receiver data processing: The receiver (lock or gateway) does not need to decrypt; it directly parses the instruction type and code in the frame header and matches the corresponding processing logic. Data validity verification is only implemented in three ways: verifying whether the instruction code is within the document definition range, verifying whether the numerical range and length of the data fields are compliant, and determining operation permissions for critical instructions by feeding back the "acceptance result." There is no data integrity verification mechanism (such as CRC or hash verification).

[0117] The process of establishing a connection between the gateway and the lock via BLE:

[0118] During the BLE connection establishment process between the gateway and the lock, the interaction sequence and key operations of each stage were clarified based on the core logic of "link establishment - session initiation - basic configuration synchronization". The specific process is as follows:

[0119] 1. Establishing the BLE Link Foundation: The gateway and the lock first complete the establishment of the BLE (Bluetooth Low Energy) underlying connection. This stage is the construction of the communication channel at the physical link level, ensuring that the two have the basic conditions for data transmission, which is the prerequisite for all subsequent command interactions.

[0120] 2. Session Initiation Request Sending and Response: After the BLE link is established, the gateway actively sends a "Session Initiation Request" instruction to the lock. This instruction is used to formally initiate the interaction session between the two and clarify the basic rules for subsequent data transmission. After receiving the request, the lock will return a "Session Initiation Request Response". The "Receive Result" field in the response (such as "Receive Permit" or "Receive Not Accepted") informs the gateway whether the session initiation request has been successfully received. Only after receiving the "Receive Permit" response will the two enter the formal interaction phase.

[0121] 3. System Information Interaction: After the session starts, the gateway immediately sends a "System Information Request" command to the lock to obtain the lock's basic system configuration information (such as log storage capacity, user ID / password management rules, function support status, etc.). After receiving the request, the lock returns a "System Information Request Response", feeding back the above system information to the gateway, so that the gateway can initially grasp the lock's basic parameters and functional status.

[0122] 4. Day and Time Synchronization Configuration: The gateway sends a "Day and Time Setting Requirement" command to transmit the current standard time (year, month, day, hour, minute, second) to the lock; after receiving it, the lock returns a "Day and Time Setting Requirement Response" to confirm that the time has been successfully synchronized, ensuring that the lock's local time is consistent with the gateway, providing an accurate time reference for subsequent log recording, timing functions (such as automatic locking time), etc.

[0123] 5. Optional remote parameter configuration (execute as needed): If it is necessary to adjust the lock's operating parameters (such as buzzer volume, automatic locking mode, number and duration of anti-accidental touches, setting button activation status, etc.), the gateway will send a "remote setting request" command with the specific parameter configuration values; after the lock receives and executes the parameter adjustment, it returns a "remote setting request response" to inform the gateway whether the parameter configuration was successful. If no parameter adjustment is required, this step is skipped.

[0124] 6. Continuous Status Notification Activation: After completing the initial configuration above, the lock will enter a continuous "system status notification" mode. Periodically or when the status changes (such as changes in the release / release status, battery power decrease, door switch status change, etc.), it will actively send a "system status notification" command to the gateway to synchronize its own operating status in real time, ensuring that the gateway maintains real-time control over the lock's status changes and maintains the validity of the connection and the timeliness of the interaction.

[0125] Regarding BLE low-power communication algorithms:

[0126] Design basis: The product needs to support low power consumption (operating current: 0.3mA in standby mode after connecting to the network, BLE is Bluetooth Low Energy 5.1).

[0127] Derivation process:

[0128] a. Algorithm logic:

[0129] Idle phase: The BLE connection interval between the gateway and the sub-device is set to 1000ms (default value) to reduce the communication frequency;

[0130] Active phase: When a command transmission (such as a command to switch a sub-device) is detected, the connection interval is dynamically shortened to 100ms (to improve response speed), and the default interval is restored after completion;

[0131] BLE broadcast optimization: The broadcast interval during the gateway configuration phase is set to 100ms (to ensure that the application installed on the sub-device can be discovered quickly), and the broadcast stops after the configuration is completed; the status reporting of the sub-device adopts the "event-triggered" mode (broadcasting only when the status changes, rather than periodic broadcasting);

[0132] b. Verification: Through actual testing, the algorithm controls the standby current to within 0.3mA.

[0133] Regarding the BLE connection distance adaptive algorithm:

[0134] Design basis: Indoor connection distance is recommended to be within 5 meters, and signal interference needs to be addressed.

[0135] Derivation process:

[0136] a. Problem Analysis: BLE signal strength (RSSI) decreases with increasing distance, requiring dynamic adjustment of transmit power to balance communication stability and power consumption;

[0137] b. Algorithm logic:

[0138] Signal detection: The gateway collects the BLE communication RSSI value with the sub-device in real time (e.g., once every 100ms);

[0139] Power adjustment rules:

[0140] If RSSI ≥ 60dBm (signal strength): set the transmit power to 20dBm (minimum, reduce power consumption);

[0141] If 80dBm≤RSSI<60dBm (moderate signal strength): set the transmit power to 0dBm;

[0142] If RSSI < 80dBm (weak signal): Set the transmit power to +8dBm (maximum, to enhance the signal);

[0143] Boundary handling: When RSSI < -90dBm is detected 5 times consecutively (distance exceeds 5 meters or there are obstacles), the gateway can push a "weak signal" prompt to the application installed on the sub-device.

[0144] In some implementations, the gateway reports BLE and Wi-Fi signals every 5 minutes, so that the server can combine this data to analyze the cause of the disconnection.

[0145] c. Hardware support: The Nordic 52840's transmit power is programmable (+8 to 20 dBm in 4 dB increments) to meet adjustment requirements.

[0146] Regarding WiFi network configuration authentication algorithm:

[0147] I. Design Basis:

[0148] In response to the EZ network configuration feature of "mobile phones not switching networks and Wi-Fi broadcasting parameters", three core safeguards are provided:

[0149] 1. SSID, password, and activation token transmission is protected against eavesdropping / tampering;

[0150] 2. Only valid gateways resolve parameters;

[0151] 3. It avoids replay attacks and unauthorized access, and meets the security specifications of IoT devices and the needs of home usability.

[0152] II. Derivation process:

[0153] a. Certification Requirements:

[0154] Verify the integrity and legality of network configuration parameters (SSID, password, activation token) to prevent the gateway from connecting to unauthorized networks;

[0155] Ensure the security of Wi-Fi broadcast parameter transmission and prevent sniffing and theft;

[0156] Prevents replay attacks and prevents unauthorized devices from parsing parameters.

[0157] b. Algorithm logic:

[0158] 1. Parameter integration and encoding (APP side)

[0159] Parameter combination: Integrates "2.4G Wi-Fi SSID + password + gateway-specific activation token (including device SN and 10-minute validity period)" to ensure that the parameters uniquely correspond to the gateway;

[0160] Protocol encoding: Encapsulated according to EZ network configuration private protocol (based on Wi-Fi 802.11 UDP), including exclusive message header (such as 0x55AA), length field, and check bit to prevent misinterpretation by non-target brand devices;

[0161] Frequency band filtering: The app automatically filters 5G Wi-Fi through the system API, only displaying 2.4G networks to avoid frequency band incompatibility issues.

[0162] 2. Secure encrypted transmission (end-to-end)

[0163] Double encryption: TLS 1.2 (transport layer, root certificate two-way authentication) + AES-128-GCM (data layer, temporary session key encryption, which expires after each network configuration key update), with a 12-byte random nonce added during encryption;

[0164] Integrity verification: AES-128-GCM generates a 128-bit MAC address. The gateway verifies the MAC address upon receiving the packet; if the verification fails, the packet is discarded.

[0165] 3. Gateway parameter parsing and verification

[0166] Packet filtering: Only capture UDP packets containing a unique header (0x55AA) to reduce resource consumption;

[0167] Decryption verification: Decrypt using the root certificate and session key to verify the uniqueness of the nonce (cache the last 5 times, duplicates are considered replay attacks); compare the SN in the token with the local SN to check the token's validity period; verify the legality of the SSID format.

[0168] 4. Connection retry and status feedback

[0169] Tiered retry: Decryption / verification failure → feedback "invalid parameter"; Wi-Fi connection failure → retry after 3 seconds on the first failure, after 2 consecutive failures the signal is checked (<-70dBm prompts "gateway and router are too far apart"), after 3 consecutive failures the indicator light flashes slowly and the APP prompts "check Wi-Fi password or router status";

[0170] Successful feedback: After the gateway connects to Wi-Fi, it sends a token to the cloud for authentication. Once authenticated, the indicator light turns off and the app displays "Network configuration successful".

[0171] Algorithm regarding Bluetooth near-field door opening function:

[0172] (1) Dual-broadcast cooperative algorithm:

[0173] Design rationale: It is necessary to balance the communication priority of sub-devices with the reachability of emergency broadcasts.

[0174] Derivation process:

[0175] Hardware constraint analysis: If the gateway Bluetooth module (such as Nordic52840) only supports single-channel broadcast, a time-division multiplexing mechanism needs to be designed;

[0176] Priority strategy: As a basic function of sub-device communication, the frequency of the second BLE broadcast is set to three times that of the third BLE broadcast to ensure that sub-device interaction is not affected, while the sub-devices can detect emergency signals.

[0177] Switchover Trigger: Broadcast switching is triggered by the connection status of the sub-device, with response delay controlled within 1 second to meet the real-time requirements of emergency scenarios.

[0178] (2) AES-ECB-128bit encryption verification algorithm

[0179] Design rationale: The confidentiality and tamper-proof nature of emergency commands must be guaranteed.

[0180] Derivation process:

[0181] Encryption method selection: The document explicitly specifies AES-ECB-128bit because this algorithm has low computational cost (suitable for embedded devices) and does not require a synchronization vector, simplifying the interaction between the gateway and the application installed on the sub-device;

[0182] Key generation logic: The key is based on the last 8 bits of the gateway MAC (e.g., “M_lj_32ac3373”), ensuring that each gateway key is unique, and because the gateway does not disclose the MAC (to prevent leakage), security is improved;

[0183] Verification mechanism: A single instruction validity check is performed using a 6-character random string to prevent replay attacks (even if the instruction is intercepted, it cannot be reused because the string is updated in real time).

[0184] (3) Random string update algorithm

[0185] Design rationale: To ensure the uniqueness of each command interaction.

[0186] Derivation process:

[0187] Length selection: A 6-character string (letters + numbers) contains approximately 2.1 billion combinations, balancing security (high difficulty in brute-force attacks) and transmission efficiency (short bytes are suitable for Bluetooth Low Energy scenarios);

[0188] Generation logic: Based on gateway hardware RNG generation, it contains uppercase and lowercase letters and numbers (each accounting for 1 / 3) to ensure randomness; each generation is compared with the previous one to avoid duplication;

[0189] Update timing: Update regardless of whether the command is executed successfully or not, to ensure that the verification factor is unique for each interaction and to prevent unauthorized duplicate requests.

[0190] Compared with the prior art, the beneficial effects of this application are as follows: When encountering situations where the sub-device cannot directly connect to the network, the gateway can maintain a Bluetooth connection with the sub-device while also connecting to the mobile device via Bluetooth. This allows users to control the sub-device through the gateway even when the Internet is unavailable, thus meeting user needs and improving the user experience. Attached Figure Description

[0191] Figure 1 This is a schematic diagram of the gateway and sub-devices in this invention.

[0192] Figure 2 This is a flowchart illustrating the method for interaction between the gateway and sub-devices in this invention. Detailed Implementation

[0193] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0194] To achieve the above objectives, the technical solution of the present invention is as follows:

[0195] See Figures 1-2 As shown, the present invention provides a gateway and a sub-device, comprising:

[0196] The gateway connects to mobile devices via Bluetooth. The gateway obtains network configuration data from the mobile devices to enable the gateway to connect to the Internet.

[0197] The sub-device connects to the gateway via Bluetooth. The sub-device is an electronic device in a smart home scenario that requires connectivity but cannot directly connect to the internet. In this scenario, the sub-device in this application can be a door lock of a specific model.

[0198] Mobile devices connect to the internet and then connect to a gateway to control the operational status of sub-devices. The mobile devices have an application installed that can interact with the gateway.

[0199] The server is connected to the Internet, and the server connects to mobile devices and a gateway via the Internet, enabling mobile devices to control the gateway to download and upgrade data from the server.

[0200] This invention provides a method for interaction between a gateway and its sub-devices, applied to a gateway, the method comprising:

[0201] Step S1: The gateway connects to the mobile device via Bluetooth to obtain network configuration data, and then connects to the Internet based on the network configuration data.

[0202] Mobile devices include electronic devices such as mobile phones, laptops, and tablets.

[0203] Step S2: The gateway connects to the sub-device via Bluetooth.

[0204] The sub-devices can be electronic devices or wearable devices used in the smart home field, such as refrigerators and speakers. In this scenario, the sub-device can be a door lock.

[0205] Step S3: Determine whether the gateway can connect to the mobile device via the Internet.

[0206] Step S4: In response to the gateway's inability to connect to the mobile device via the Internet, the gateway establishes a Bluetooth connection with the mobile device while maintaining a Bluetooth connection with the sub-device.

[0207] Compared with the prior art, the beneficial effects of this application are as follows: When encountering situations where the sub-device cannot directly connect to the network, the gateway can maintain a Bluetooth connection with the sub-device while also connecting to the mobile device via Bluetooth. This allows users to control the sub-device through the gateway even when the Internet is unavailable, thus meeting user needs and improving the user experience.

[0208] Step S1: The gateway connects to the mobile device via Bluetooth to obtain network configuration data. Based on this network configuration data, the gateway connects to the Internet, including:

[0209] Step S11: The gateway sends the first BLE broadcast to connect to the mobile device via BLE. The mobile device has an application installed that can interact with the gateway.

[0210] After the gateway is powered on, it automatically enters network configuration mode and broadcasts its identification information via BLE. The application controls mobile devices to search for the first BLE broadcast, establishes a BLE connection with the gateway, obtains the gateway's identification information, sends the gateway's identification information to the server, and requests registration.

[0211] The gateway is equipped with an indicator light that flashes rapidly when the gateway enters the network configuration mode. Preferably, the indicator light flashes twice per second.

[0212] The gateway's identification information includes the gateway's DID (Device Identifier), X-API-Key, vendor, and PID (Product ID). The DID is a string or code used to uniquely identify the gateway device, distinguishing different gateways within the network and enabling functions such as device management, data traceability, and communication authentication. In this embodiment, the gateway's BLE MAC address is used as the DID.

[0213] BLE (Bluetooth Low Energy) is a wireless technology standard designed for low-power, short-range wireless communication and is widely used in the Internet of Things, wearable devices, smart homes and other fields.

[0214] Step 12: The gateway obtains and parses network configuration data from the mobile device, and connects to the Internet based on the parsed network configuration data.

[0215] Users input network configuration data into an application on their mobile devices. The application controls the mobile device to send the network configuration data to the gateway via a BLE connection. The gateway retrieves and parses the network configuration data from the mobile device, connects to the corresponding router, and thus connects to the internet. The network configuration data includes the Wi-Fi name and password.

[0216] When the gateway is connected to the network, the indicator light flashes slowly. Preferably, the indicator light flashes slowly once every 2 seconds.

[0217] Step S13: Determine whether the gateway is connected to the Internet.

[0218] Step S14: In response to the gateway connecting to the Internet, the gateway uploads version data to the server via the Internet, receives MQTT topics sent by the server via the Internet, and subscribes to MQTT topics.

[0219] Preferably, the gateway receives the MQTT topic and token sent by the server via the Internet.

[0220] In this context, a token is a temporary credential used in a computer system to identify identity, permissions, or status. It is typically generated by the server and returned to the gateway. Subsequent requests from the gateway must include this token to verify its legitimacy.

[0221] Version data includes the current firmware version number of the gateway. Firmware is a special type of software that is directly burned into the gateway's read-only memory (ROM), flash memory, or electrically erasable programmable read-only memory (EEPROM). It provides the hardware with an initialization instruction set, ensuring that the gateway can start correctly and perform basic operations after power-on.

[0222] MQTT (Message Queuing Telemetry Transport) topics are paths in the MQTT protocol used to identify message publishing and subscription.

[0223] Step S15: In response to the gateway not being connected to the Internet, the gateway sends network configuration failure data to the mobile device via the BLE connection.

[0224] The gateway sends network configuration failure data to the mobile device via BLE connection, and the mobile device's application displays "Network configuration failed".

[0225] When the gateway is not connected to the Internet, the gateway indicator light will continue to flash; the light will turn off once the connection is successful.

[0226] Step S2, the gateway connects to the sub-device via Bluetooth, including:

[0227] Step S21: The gateway sends a second BLE broadcast to perform a BLE scan and search for BLE broadcasts from nearby sub-devices.

[0228] Step S22: The gateway establishes a BLE connection with the sub-device, performs authentication through a preset protocol, and establishes a communication session between the gateway and the sub-device.

[0229] The communication session can be a MW session, which is related to the interface of the mobile core network.

[0230] Step S23: The gateway receives the sub-device's identity data through a communication session and sends the sub-device's identity data to the server via the Internet to request registration.

[0231] The identification data of the sub-device includes information such as the sub-device's DID, on / off status, and power level.

[0232] Step S24: The gateway receives MQTT topics sent by the server via the Internet, subscribes to MQTT topics, and records the binding information of sub-devices.

[0233] After the gateway completes this step, the server sends "Sub-device registration successful" data to the mobile device and synchronizes the current sub-device status. The application installed on the mobile device displays "Added successfully".

[0234] The gateway records the binding information of the sub-devices to support subsequent communication.

[0235] Step S4: The gateway establishes a Bluetooth connection with the mobile device while maintaining the Bluetooth connection with the sub-device, including:

[0236] Step S41: The gateway sends a third BLE broadcast at the same time as sending the second BLE broadcast;

[0237] After the gateway starts up, it maintains two sets of broadcasts simultaneously. The second BLE broadcast sends signals for interaction with sub-devices according to the original mechanism. These signals include information such as device identifier and connection status. The third BLE broadcast is used for emergency communication with mobile devices, sending signals containing an emergency identifier to the mobile devices. The field format of this signal is: Emergency Identifier + Device ID.

[0238] Preferably, the sending rules for the second and third BLE broadcasts are as follows: if the gateway hardware supports parallel sending, they are started simultaneously; if not, the second BLE broadcast is sent first, and the third BLE broadcast is inserted every 500ms.

[0239] Preferably, the dynamic switching mechanism between the second and third BLE broadcasts is as follows: when the gateway maintains a connection with the sub-device, both broadcasts are continuously sent; if the connection between the gateway and the sub-device is interrupted, the third BLE broadcast is immediately stopped, only the second BLE broadcast is sent, and an attempt is made to reconnect to the sub-device; after a successful reconnection, the sending of the third BLE broadcast is resumed.

[0240] Step S42: The gateway establishes a BLE connection with the mobile device through a third BLE broadcast, generates verification data, and sends the verification data to the mobile device. The verification data includes a first verification string and a sub-device status string.

[0241] In this embodiment, the gateway stores the first verification string locally.

[0242] Preferably, the verification data also includes an empty string, which is used to pad the length of the verification data to meet the requirements of the encryption algorithm. That is, the verification data consists of a first verification string, a sub-device status string, and an empty string. The first verification string can be a 6-character random string.

[0243] In some implementations, the encryption algorithm limits the string length of the verification data to 16 bits, and an empty string is used to pad the string length of the verification data to 16 bits.

[0244] Step S43: The gateway and mobile device perform encrypted transmission.

[0245] The mobile device receives and stores the verification data, and the application installed on the mobile device sends a message indicating "Connection successful".

[0246] For details on the encrypted transmission process, please refer to steps S431-S436.

[0247] Step S43, the gateway and mobile device perform encrypted transmission, including:

[0248] Step S431: The gateway receives the encryption command sent by the mobile device and decrypts the encryption command using a preset key to obtain a decryption string, which includes a second verification string and a command string.

[0249] The mobile device concatenates the control command with a second verification string obtained through verification data to obtain the command to be encrypted. Preferably, the command to be encrypted may also include an empty string, which is used to pad the length of the command to meet the requirements of the encryption algorithm. That is, the command to be encrypted consists of a second verification string, a control command, and an empty string. The second verification string can be a 6-character random string.

[0250] Preferably, the mobile device can use AES ECB 128bit to encrypt the command to be encrypted, obtain the encrypted command, and send the encrypted command to the gateway.

[0251] The gateway receives encrypted commands sent by mobile devices and decrypts them using a preset key to obtain a decrypted string. The preset key can be in the format: M_lj_[last 8 bits of the gateway's MAC address], for example, M_lj_32ac3373.

[0252] Step S432: The gateway verifies whether the second verification string in the decryption string is consistent with the first verification string.

[0253] Step S433: In response to the second verification string in the decryption string being consistent with the first verification string, the gateway sends the instruction corresponding to the instruction string to the sub-device.

[0254] Step S434: The gateway updates the first verification string in the verification data and obtains the status of the sub-device to update the sub-device status string in the verification data.

[0255] When the status of a sub-device changes, the gateway synchronously updates the sub-device status string.

[0256] Step S435: The gateway sends the updated sub-device status string to the mobile device.

[0257] When the status of a sub-device changes, the gateway synchronously updates the sub-device status string and sends the updated sub-device status string to the mobile device.

[0258] Step S436: In response to the discrepancy between the second verification string and the first verification string in the decryption string, the gateway updates the first verification string in the verification data and sends an instruction to the mobile device to invalidate data.

[0259] Regardless of whether the second verification string in the decryption string is the same as the first verification string, the gateway randomly generates a new first verification string.

[0260] Step S42: The gateway establishes a BLE connection with the mobile device via a third BLE broadcast, generates authentication data, and sends the authentication data to the mobile device, followed by:

[0261] Step S421: Determine whether the BLE connection established between the gateway and the mobile device is interrupted.

[0262] Step S422: In response to the interruption of the BLE connection established between the gateway and the mobile device, the gateway saves the current data and determines whether the gateway will establish a BLE connection with the mobile device within a preset time.

[0263] Preferably, the preset time can be 30 seconds.

[0264] Step S423: In response to the gateway failing to establish a BLE connection with the mobile device within a preset time, the gateway clears the current data and sends a third BLE broadcast.

[0265] After the gateway connects to the internet and connects to the sub-devices via Bluetooth, users can initiate requests such as "Turn sub-device on / off," "Delete sub-device," "Delete gateway," and "Upgrade request" through the application installed on their mobile devices. The specific workflow of the gateway in each request is as follows:

[0266] When a user initiates an "on / off sub-device" request on an application installed on a mobile device, the gateway's workflow is as follows:

[0267] Step S51: The gateway receives the switch command for the sub-device sent by the server through the MQTT topic, parses the switch command for the sub-device, and sends the target command to the sub-device.

[0268] Users send "on / off sub-device" requests to the server through applications installed on their mobile devices, and the server sends the sub-device on / off instructions to the gateway via an MQTT topic.

[0269] Step S52: The gateway receives the current status data sent by the sub-device through the BLE connection, and then synchronizes the current status data to the server.

[0270] After the sub-device executes the command, it sends its current status data (such as "on" or "off") to the gateway via the BLE connection. The gateway then synchronizes the current status data to the server, which in turn pushes it to the application installed on the mobile device. The application updates and displays the sub-device's status. If the sub-device fails to execute the command (e.g., the BLE connection is interrupted), the gateway reports an error to the server, and the application installed on the mobile device displays "Operation failed."

[0271] When a user initiates a "Delete Sub-device" request on an application installed on a mobile device, the gateway's workflow is as follows:

[0272] Step S61: The gateway receives the delete sub-device instruction via MQTT topic.

[0273] The user sends a "delete sub-device" request to the server through an application installed on their mobile device. The application controls the mobile device to send the sub-device's DID to the server. The server then sends the delete sub-device command to the gateway via an MQTT topic.

[0274] Step S62: The gateway clears the binding information of the sub-device and disconnects the BLE connection with the sub-device;

[0275] Preferably, after the gateway completes this step, it needs to be restarted to complete the instruction to delete the sub-device. The server sends a notification "Sub-device has been deleted" to the application installed on the mobile device.

[0276] When a user initiates a "Remove Gateway" request on an application installed on a mobile device, the gateway's workflow is as follows:

[0277] Step S71: The gateway receives the delete gateway command via the MQTT topic.

[0278] The user sends a "delete gateway" request to the server through an application installed on their mobile device. The mobile device then sends the gateway's DID to the server. The server then sends a delete gateway command to the gateway via an MQTT topic.

[0279] Step S72: The gateway clears the network configuration data and disconnects from the server.

[0280] Network configuration data includes Wi-Fi network configuration data. The indicator light on the gateway resumes fast flashing, indicating that the network configuration mode has been entered. Preferably, the server sends a notification "Gateway has been deleted" to the application installed on the mobile device.

[0281] When the server detects a new version of the gateway firmware, or when a user initiates an "upgrade request" on an application installed on a mobile device, the gateway's workflow is as follows:

[0282] Step S81: The gateway receives the upgrade command sent by the server through the MQTT topic, and downloads the upgrade data from the server through an HTTPS request.

[0283] Users send an "upgrade request" to the server through an application installed on their mobile devices. The server then sends an upgrade command to the gateway via an MQTT topic. The gateway downloads the upgrade data from the server via an HTTPS request.

[0284] The upgrade instructions include OTA (Over-the-Air Technology) instructions. Preferably, the OTA instructions include the firmware version and a download link. OTA is a technology that uses wireless communication networks (such as mobile networks, Bluetooth, etc.) to remotely update the software, manage the configuration, or transmit data to a gateway.

[0285] HTTPS (Hypertext Transfer Protocol Secure) is a secure data transmission protocol that adds an SSL / TLS (Secure Sockets Layer / Transport Layer Security) protocol layer to HTTP to ensure that data is encrypted and protected during transmission between the client and the server.

[0286] Upgrade data may include upgrading the gateway's firmware. Firmware is a special type of software that is directly burned into the gateway's read-only memory (ROM), flash memory, or electrically erasable programmable read-only memory (EEPROM). It provides the hardware with an initialization instruction set, ensuring that the gateway can start correctly and perform basic operations after power-on.

[0287] Step S82: The gateway verifies whether the upgrade data is complete.

[0288] Preferably, CRC detection technology can be used to verify whether the upgrade data is complete. CRC (Cyclic Redundancy Check) is an error detection technology widely used in data communication and storage. It verifies whether errors have occurred in the data during transmission or storage by calculating the check value of the data.

[0289] Step S83: In response to the completeness of the upgrade data downloaded by the gateway, the gateway installs the upgrade data, automatically restarts after installation, and reports the current version data to the server.

[0290] The gateway incorporates flash memory and features indicator lights. When installing upgrade data, the gateway writes the upgrade data to the flash memory. During the upgrade process, the indicator lights flash rapidly, and the gateway automatically restarts upon completion. Preferably, the indicator lights flash twice per second.

[0291] The version data includes the firmware version number of the newly installed firmware.

[0292] Step S84: In response to the incomplete upgrade data downloaded by the gateway, the gateway reports an error to the server.

[0293] If the gateway detects that the upgrade data downloaded is incomplete, the gateway will revert to the original version, the indicator light will flash slowly, and the gateway will restart. After restarting, the indicator light will turn off.

[0294] When a user manually operates a sub-device, the gateway's workflow is as follows:

[0295] Step S91: The gateway receives the current status data sent by the sub-device via the BLE connection.

[0296] After detecting manual operation, the sub-device updates its current operating status and sends the current status data to the gateway.

[0297] Step S92: The gateway sends the current status data to the server via an MQTT topic.

[0298] Preferably, after the gateway completes this step, the server sends the current status data to the mobile device, and the application installed on the mobile device displays the current status of the sub-device in real time.

[0299] To ensure secure communication between the gateway and sub-devices, and between the gateway and the server, and to prevent data from being tampered with or eavesdropped on, transmitted commands (such as "turn sub-device on / off", "delete sub-device", "delete gateway", "upgrade request") and status information (such as the status of sub-devices) must be encrypted.

[0300] Regarding the choice of encryption algorithm: based on the hardware support of the gateway (using the Nordic52840 chip, which contains a 128-bit AES-128-CCM / ECB encryption module), the AES-128-CCM algorithm is selected for encryption, which balances encryption and integrity verification.

[0301] Regarding key management:

[0302] Gateway and server keys: During registration, the server generates a random 128-bit key, which is sent to the gateway through an encrypted channel (such as HTTPS) and stored in the built-in FLASH.

[0303] Gateway and lock keys: There is no key-related mechanism in the interaction between the gateway and the lock. After establishing a connection via BLE, the two only initiate interaction through a "session start request" command. Preferably, this command adopts an "unencrypted" and "unsigned" strategy, and the interaction between the gateway and the lock relies on fixed command codes and data format verification to achieve basic control.

[0304] Regarding the encryption process:

[0305] Data processing by the sender: The sender (gateway or lock) encapsulates data in a fixed format of "frame header (HEAD) + data segment (DATA)". The frame header contains control information such as instruction type and instruction code, and the data segment contains specific business data (such as lock status, registration information, etc.). The entire process involves no encryption; data is transmitted in plaintext, and the encapsulation format does not include data length or checksum fields.

[0306] Receiver data processing: The receiver (lock or gateway) does not need to decrypt; it directly parses the instruction type and code in the frame header and matches the corresponding processing logic. Data validity verification is only implemented in three ways: verifying whether the instruction code is within the document definition range, verifying whether the numerical range and length of the data fields are compliant, and determining operation permissions for critical instructions by feeding back the "acceptance result." There is no data integrity verification mechanism (such as CRC or hash verification).

[0307] The process of establishing a connection between the gateway and the lock via BLE:

[0308] During the BLE connection establishment process between the gateway and the lock, the interaction sequence and key operations of each stage were clarified based on the core logic of "link establishment - session initiation - basic configuration synchronization". The specific process is as follows:

[0309] 1. Establishing the BLE Link Foundation: The gateway and the lock first complete the establishment of the BLE (Bluetooth Low Energy) underlying connection. This stage is the construction of the communication channel at the physical link level, ensuring that the two have the basic conditions for data transmission, which is the prerequisite for all subsequent command interactions.

[0310] 2. Session Initiation Request Sending and Response: After the BLE link is established, the gateway actively sends a "Session Initiation Request" instruction to the lock. This instruction is used to formally initiate the interaction session between the two and clarify the basic rules for subsequent data transmission. After receiving the request, the lock will return a "Session Initiation Request Response". The "Receive Result" field in the response (such as "Receive Permit" or "Receive Not Accepted") informs the gateway whether the session initiation request has been successfully received. Only after receiving the "Receive Permit" response will the two enter the formal interaction phase.

[0311] 3. System Information Interaction: After the session starts, the gateway immediately sends a "System Information Request" command to the lock to obtain the lock's basic system configuration information (such as log storage capacity, user ID / password management rules, function support status, etc.). After receiving the request, the lock returns a "System Information Request Response", feeding back the above system information to the gateway, so that the gateway can initially grasp the lock's basic parameters and functional status.

[0312] 4. Day and Time Synchronization Configuration: The gateway sends a "Day and Time Setting Requirement" command to transmit the current standard time (year, month, day, hour, minute, second) to the lock; after receiving it, the lock returns a "Day and Time Setting Requirement Response" to confirm that the time has been successfully synchronized, ensuring that the lock's local time is consistent with the gateway, providing an accurate time reference for subsequent log recording, timing functions (such as automatic locking time), etc.

[0313] 5. Optional remote parameter configuration (execute as needed): If it is necessary to adjust the lock's operating parameters (such as buzzer volume, automatic locking mode, number and duration of anti-accidental touches, setting button activation status, etc.), the gateway will send a "remote setting request" command with the specific parameter configuration values; after the lock receives and executes the parameter adjustment, it returns a "remote setting request response" to inform the gateway whether the parameter configuration was successful. If no parameter adjustment is required, this step is skipped.

[0314] 6. Continuous Status Notification Activation: After completing the initial configuration above, the lock will enter a continuous "system status notification" mode. Periodically or when the status changes (such as changes in the release / release status, battery power decrease, door switch status change, etc.), it will actively send a "system status notification" command to the gateway to synchronize its own operating status in real time, ensuring that the gateway maintains real-time control over the lock's status changes and maintains the validity of the connection and the timeliness of the interaction.

[0315] Regarding BLE low-power communication algorithms:

[0316] Design basis: The product needs to support low power consumption (operating current: 0.3mA in standby mode after connecting to the network, BLE is Bluetooth Low Energy 5.1).

[0317] Derivation process:

[0318] a. Algorithm logic:

[0319] Idle phase: The BLE connection interval between the gateway and the sub-device is set to 1000ms (default value) to reduce the communication frequency;

[0320] Active phase: When a command transmission (such as a command to switch a sub-device) is detected, the connection interval is dynamically shortened to 100ms (to improve response speed), and the default interval is restored after completion;

[0321] BLE broadcast optimization: The broadcast interval during the gateway configuration phase is set to 100ms (to ensure that the application installed on the sub-device can be discovered quickly), and the broadcast stops after the configuration is completed; the status reporting of the sub-device adopts the "event-triggered" mode (broadcasting only when the status changes, rather than periodic broadcasting);

[0322] b. Verification: Through actual testing, the algorithm controls the standby current to within 0.3mA.

[0323] Regarding the BLE connection distance adaptive algorithm:

[0324] Design basis: Indoor connection distance is recommended to be within 5 meters, and signal interference needs to be addressed.

[0325] Derivation process:

[0326] a. Problem Analysis: BLE signal strength (RSSI) decreases with increasing distance, requiring dynamic adjustment of transmit power to balance communication stability and power consumption;

[0327] b. Algorithm logic:

[0328] Signal detection: The gateway collects the BLE communication RSSI value with the sub-device in real time (e.g., once every 100ms);

[0329] Power adjustment rules:

[0330] If RSSI ≥ 60dBm (signal strength): set the transmit power to 20dBm (minimum, reduce power consumption);

[0331] If 80dBm≤RSSI<60dBm (moderate signal strength): set the transmit power to 0dBm;

[0332] If RSSI < 80dBm (weak signal): Set the transmit power to +8dBm (maximum, to enhance the signal);

[0333] Boundary handling: When RSSI < -90dBm is detected 5 times consecutively (distance exceeds 5 meters or there are obstacles), the gateway can push a "weak signal" prompt to the application installed on the sub-device.

[0334] In some implementations, the gateway reports BLE and Wi-Fi signals every 5 minutes, so that the server can combine this data to analyze the cause of the disconnection.

[0335] c. Hardware support: The Nordic 52840's transmit power is programmable (+8 to 20 dBm in 4 dB increments) to meet adjustment requirements.

[0336] Regarding WiFi network configuration authentication algorithm:

[0337] I. Design Basis:

[0338] In response to the EZ network configuration feature of "mobile phones not switching networks and Wi-Fi broadcasting parameters", three core safeguards are provided:

[0339] 1. SSID, password, and activation token transmission is protected against eavesdropping / tampering;

[0340] 2. Only valid gateways resolve parameters;

[0341] 3. It avoids replay attacks and unauthorized access, and meets the security specifications of IoT devices and the needs of home usability.

[0342] II. Derivation process:

[0343] a. Certification Requirements:

[0344] Verify the integrity and legality of network configuration parameters (SSID, password, activation token) to prevent the gateway from connecting to unauthorized networks;

[0345] Ensure the security of Wi-Fi broadcast parameter transmission and prevent sniffing and theft;

[0346] Prevents replay attacks and prevents unauthorized devices from parsing parameters.

[0347] b. Algorithm logic:

[0348] 1. Parameter integration and encoding (APP side)

[0349] Parameter combination: Integrates "2.4G Wi-Fi SSID + password + gateway-specific activation token (including device SN and 10-minute validity period)" to ensure that the parameters uniquely correspond to the gateway;

[0350] Protocol encoding: Encapsulated according to EZ network configuration private protocol (based on Wi-Fi 802.11 UDP), including exclusive message header (such as 0x55AA), length field, and check bit to prevent misinterpretation by non-target brand devices;

[0351] Frequency band filtering: The app automatically filters 5G Wi-Fi through the system API, only displaying 2.4G networks to avoid frequency band incompatibility issues.

[0352] 2. Secure encrypted transmission (end-to-end)

[0353] Double encryption: TLS 1.2 (transport layer, root certificate two-way authentication) + AES-128-GCM (data layer, temporary session key encryption, which expires after each network configuration key update), with a 12-byte random nonce added during encryption;

[0354] Integrity verification: AES-128-GCM generates a 128-bit MAC address. The gateway verifies the MAC address upon receiving the packet; if the verification fails, the packet is discarded.

[0355] 3. Gateway parameter parsing and verification

[0356] Packet filtering: Only capture UDP packets containing a unique header (0x55AA) to reduce resource consumption;

[0357] Decryption verification: Decrypt using the root certificate and session key to verify the uniqueness of the nonce (cache the last 5 times, duplicates are considered replay attacks); compare the SN in the token with the local SN to check the token's validity period; verify the legality of the SSID format.

[0358] 4. Connection retry and status feedback

[0359] Tiered retry: Decryption / verification failure → feedback "invalid parameter"; Wi-Fi connection failure → retry after 3 seconds on the first failure, after 2 consecutive failures the signal is checked (<-70dBm prompts "gateway and router are too far apart"), after 3 consecutive failures the indicator light flashes slowly and the APP prompts "check Wi-Fi password or router status";

[0360] Successful feedback: After the gateway connects to Wi-Fi, it sends a token to the cloud for authentication. Once authenticated, the indicator light turns off and the app displays "Network configuration successful".

[0361] Algorithm regarding Bluetooth near-field door opening function:

[0362] (1) Dual-broadcast cooperative algorithm:

[0363] Design rationale: It is necessary to balance the communication priority of sub-devices with the reachability of emergency broadcasts.

[0364] Derivation process:

[0365] Hardware constraint analysis: If the gateway Bluetooth module (such as Nordic52840) only supports single-channel broadcast, a time-division multiplexing mechanism needs to be designed;

[0366] Priority strategy: As a basic function of sub-device communication, the frequency of the second BLE broadcast is set to three times that of the third BLE broadcast to ensure that sub-device interaction is not affected, while the sub-devices can detect emergency signals.

[0367] Switchover Trigger: Broadcast switching is triggered by the connection status of the sub-device, with response delay controlled within 1 second to meet the real-time requirements of emergency scenarios.

[0368] (2) AES-ECB-128bit encryption verification algorithm

[0369] Design rationale: The confidentiality and tamper-proof nature of emergency commands must be guaranteed.

[0370] Derivation process:

[0371] Encryption method selection: The document explicitly specifies AES-ECB-128bit because this algorithm has low computational cost (suitable for embedded devices) and does not require a synchronization vector, simplifying the interaction between the gateway and the application installed on the sub-device;

[0372] Key generation logic: The key is based on the last 8 bits of the gateway MAC (e.g., “M_lj_32ac3373”), ensuring that each gateway key is unique, and because the gateway does not disclose the MAC (to prevent leakage), security is improved;

[0373] Verification mechanism: A single instruction validity check is performed using a 6-character random string to prevent replay attacks (even if the instruction is intercepted, it cannot be reused because the string is updated in real time).

[0374] (3) Random string update algorithm

[0375] Design rationale: To ensure the uniqueness of each command interaction.

[0376] Derivation process:

[0377] Length selection: A 6-character string (letters + numbers) contains approximately 2.1 billion combinations, balancing security (high difficulty in brute-force attacks) and transmission efficiency (short bytes are suitable for Bluetooth Low Energy scenarios);

[0378] Generation logic: Based on gateway hardware RNG generation, it contains uppercase and lowercase letters and numbers (each accounting for 1 / 3) to ensure randomness; each generation is compared with the previous one to avoid duplication;

[0379] Update timing: Update regardless of whether the command is executed successfully or not, to ensure that the verification factor is unique for each interaction and to prevent unauthorized duplicate requests.

[0380] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A gateway and a sub-device, characterized in that, include: The gateway connects to mobile devices via Bluetooth, and obtains network configuration data from the mobile devices to enable the gateway to connect to the Internet. Sub-devices connect to the gateway via Bluetooth; Mobile devices connect to the internet and then connect to a gateway to control the operating status of sub-devices. The server is connected to the Internet, and the server connects to mobile devices and a gateway via the Internet, enabling mobile devices to control the gateway to download and upgrade data from the server.

2. A method for interaction between a gateway and a sub-device, applied to a gateway, characterized in that, The method includes: The gateway connects to mobile devices via Bluetooth to obtain network configuration data, and then connects to the Internet based on the network configuration data. The gateway connects to the sub-devices via Bluetooth; Determine if the gateway can connect to mobile devices via the internet; In response to the gateway's inability to connect to the mobile device via the internet, the gateway maintains its Bluetooth connection with the sub-device while simultaneously establishing a Bluetooth connection with the mobile device.

3. The method according to claim 2, characterized in that, The gateway connects to mobile devices via Bluetooth to obtain network configuration data. Based on this network configuration data, the gateway connects to the Internet, including: The gateway sends the first BLE broadcast to connect to the mobile device via BLE; The gateway obtains and parses network configuration data from mobile devices, and connects to the Internet based on the parsed network configuration data; Determine if the gateway is connected to the internet; In response to the gateway connecting to the Internet, the gateway uploads version data to the server via the Internet, receives MQTT topics sent by the server via the Internet, and subscribes to MQTT topics; In response to the gateway not being connected to the Internet, the gateway sends network configuration failure data to the mobile device via a BLE connection.

4. The method according to claim 3, characterized in that, The gateway connects to the sub-devices via Bluetooth, including: The gateway sends a second BLE broadcast to perform a BLE scan and search for BLE broadcasts from nearby sub-devices. The gateway establishes a BLE connection with the sub-device, performs authentication through a preset protocol, and establishes a communication session between the gateway and the sub-device. The gateway receives the sub-device's identity data through a communication session and sends the sub-device's identity data to the server via the Internet to request registration; The gateway receives MQTT topics sent by the server via the Internet, subscribes to MQTT topics, and records the binding information of sub-devices.

5. The method according to any one of claims 2-4, characterized in that, The gateway maintains a Bluetooth connection with the sub-device while simultaneously establishing a Bluetooth connection with the mobile device, including: The gateway sends a third BLE broadcast at the same time as sending the second BLE broadcast; The gateway establishes a BLE connection with the mobile device through a third BLE broadcast, generates verification data, and sends the verification data to the mobile device. The verification data includes a first verification string and a sub-device status string. The gateway transmits data encrypted to and from mobile devices.

6. The method according to claim 5, characterized in that, The gateway performs encrypted transmission with the mobile device, including: The gateway receives the encrypted command sent by the mobile device and decrypts the encrypted command using a preset key to obtain a decryption string, which includes a second verification string and a command string; The gateway verifies whether the second verification string in the decryption string matches the first verification string. If the second verification string in the decryption string matches the first verification string, the gateway sends the instruction corresponding to the instruction string to the sub-device. The gateway updates the first verification string in the verification data and obtains the status of the sub-device to update the sub-device status string in the verification data. The gateway sends the updated sub-device status string to the mobile device; If the second verification string in the decryption string is inconsistent with the first verification string, the gateway updates the first verification string in the verification data and sends an instruction for invalid data to the mobile device.

7. The method according to claim 5, characterized in that, The gateway establishes a BLE connection with the mobile device via a third BLE broadcast, generates authentication data, and sends the authentication data to the mobile device, followed by: Determine whether the BLE connection established between the gateway and the mobile device is interrupted; In response to the interruption of the BLE connection established between the gateway and the mobile device, the gateway saves the current data and determines whether the gateway will establish a BLE connection with the mobile device within a preset time. If the gateway fails to establish a BLE connection with the mobile device within a preset time, the gateway will clear the current data and send a third BLE broadcast.

8. The method according to claim 4, characterized in that, After the gateway is connected to the internet and then connected to the sub-device via Bluetooth... When a mobile device initiates a "turn sub-device on / off" request, the gateway's workflow includes: The gateway receives the on / off instructions for sub-devices sent by the server via MQTT topics, parses the on / off instructions for sub-devices, and sends the target instructions to the sub-devices; The gateway receives current status data sent by the sub-devices via BLE connection, and then synchronizes the current status data to the server.

9. The method according to claim 4, characterized in that, After the gateway is connected to the internet and then connected to the sub-device via Bluetooth... When a mobile device initiates a "remove sub-device" request, the gateway's workflow includes: The gateway receives the command to delete a sub-device via an MQTT topic; The gateway clears the binding information of the sub-device and disconnects the BLE connection from the sub-device. When a mobile device initiates a "delete gateway" request, the gateway's workflow includes: The gateway receives the delete gateway command via an MQTT topic; The gateway clears network configuration data and disconnects from the server.

10. The method according to claim 4, characterized in that, After the gateway is connected to the internet and then connected to the sub-device via Bluetooth... When the server detects a new version of the gateway firmware, or when a mobile device initiates an "upgrade request," the gateway's workflow includes: The gateway receives upgrade instructions sent by the server via MQTT topics, and downloads upgrade data from the server via HTTPS requests; The gateway verifies whether the upgrade data is complete. If the upgrade data downloaded by the gateway is complete, the gateway will install the upgrade data, automatically restart after installation, and report the current version data to the server. In response to incomplete upgrade data downloaded by the gateway, the gateway reports an error to the server; When a user manually operates a sub-device, the gateway's workflow includes: The gateway receives current status data sent by the sub-devices via a BLE connection; The gateway sends current status data to the server via MQTT topics.

Images