Intelligent light device based on bluetooth communication and control method

Abstract

This invention relates to a smart lighting device and control method based on Bluetooth communication. The device establishes a GATT service based on BLE, sets write features to receive client commands, and sets notification features to actively report responses and status. Command data adopts a unified and universal frame structure, including a frame header, length, command category, sub-function, payload, and verification field; the device verifies the data before parsing. The device side sets up a business logic arbitration engine to arbitrate command requests along with charging status, battery voltage, and sensor events, outputting the final execution command and driving the lights according to charging mutual exclusion, low battery protection, and multi-working-mode coordination rules. For stepless dimming, a non-reply write throttling process is used, and a confirmation packet is sent at the end of the process, triggering synchronous status reporting to achieve smooth interaction and eventual consistency. After disconnection and light shutdown, the device enters deep sleep and is awakened by vibration to trigger simultaneous lighting and reporting, reducing power consumption and improving availability.

Description

Technical Field

[0001] This invention relates to the fields of IoT smart lighting and embedded Bluetooth communication technology, and to a smart lighting device and control method based on Bluetooth communication. In particular, it relates to a smart lighting device and control method that achieves coordinated lighting control, sensor event interaction and power management based on a layered instruction frame structure and device-side business logic arbitration under Bluetooth Low Energy (BLE) communication. Background Technology

[0002] Most existing Bluetooth smart lights adopt a simple "command-execute-return" mode, typically only covering basic controls such as switching, dimming, and color temperature / mode adjustment, which has the following problems: 1) Lighting control, power management, and sensor perception are independent of each other, and lighting behavior conflicts or asynchronous states are likely to occur in charging, low power, and sleep states. 2) The protocol has weak extensibility, and adding new functions often requires redefining multiple sets of instructions, resulting in poor compatibility between the client and the firmware; 3) Continuous interactions (such as brightness swiping) either require confirmation, causing lag and delay, or lack of confirmation, leading to inconsistent final states; 4) The lack of a strong rule-based decision-making mechanism on the device side results in an inability to maintain reasonable behavior during brief Bluetooth disconnections, leading to insufficient user experience and security. Summary of the Invention

[0003] (a) Purpose of the invention This invention aims to provide a smart lighting device and control method based on Bluetooth communication. By defining a general frame structure and a hierarchical instruction set, and setting up a business logic arbitration engine on the device side, the light output, sensor events and power status are strongly constrained and coordinated to achieve integrated control of "reliable instruction closed loop + smooth and continuous interaction + mutual exclusion of safe status + active event reporting".

[0004] (II) Technical Solution To address the problems that existing Bluetooth smart lighting devices often encounter in practical use, such as inconsistencies between command execution and device status, conflicts between lighting control and charging / low battery protection, stuttering or packet loss during continuous dimming interaction, high power consumption during disconnection and poor availability in disconnection scenarios, this invention provides a smart lighting device and control method based on Bluetooth communication, including the following: The overall technical architecture of this invention can be summarized as a "three-layer integrated" collaborative approach: the first is the standard transmission layer, which provides connection and data channels based on Bluetooth Low Energy (BLE) GATT; the second is the proprietary protocol layer, which defines a general frame structure on top of GATT, including frame header, length, instruction category, sub-function, payload, and check field, and adopts a hierarchical instruction set of "instruction category + sub-function key" for unified parsing and expansion; the third is the business logic layer, which sets a business logic arbitration engine in the device firmware to perform strong constraint arbitration on instruction requests, sensor events, and power status from the proprietary protocol layer before outputting the final execution command, thereby forming an indivisible overall control scheme.

[0005] The smart lighting device establishes a GATT communication interface based on Bluetooth Low Energy (BLE). A first characteristic value is set to receive data packets sent by the client (supporting write with and without reply). A second characteristic value is set to allow the device to actively report responses, status, events, and error information via Notify.

[0006] The data interaction between the device and the client adopts a unified general frame structure. The general frame structure includes at least a frame header, length, command ID, sub-function key, parameter payload data, and checksum field. Before entering the business processing, the device verifies the frame header and checksum field. If the verification fails or the parameter is invalid, an error frame containing the source command ID, source key, and error code is reported through the second feature value. Command ID is used to distinguish macro-level business categories. Its value can be obtained using an example mapping method: for example, 0x01 represents lighting control, 0x02 represents sensor configuration / event, 0x03 represents device management / power management, and 0xFF represents error handling. The sub-function Key is used to further distinguish specific operations under the same command ID. The above values ​​are just examples and can be adjusted according to the product definition, as long as the principle of "the combination of Command ID and Key uniquely determines the operation type" is met.

[0007] After successful verification, the device parses the combination of Command ID and Key to determine the type of operation to be executed. The operation type includes at least lighting control operations, sensor and configuration operations, and device information / power management operations. The device is equipped with a business logic arbitration engine. The operation to be executed, the power management status (battery voltage, charging status, protection flag) and sensor events are jointly input into the arbitration engine for arbitration. According to the rules such as charging mutual exclusion, low power protection and multi-working mode coordination, the final execution command and allow / reject flag are output. When allowed, the light module is driven to output the corresponding constant light, breathing, flashing, mixed color and / or independent channel brightness control. When rejected, the corresponding error code is returned. After execution, the device reports ACK and light status / sensor events / power status via Notify to achieve control closed loop and observability; Meanwhile, to balance the smoothness of continuous interaction with the consistency of the final state, this invention stipulates that click / mode switching operations use write with reply to ensure the consistency of key states, while brightness stepless sliding operations use write without reply and are sent by the client in a throttled manner. At the end of the sliding, a write with reply is sent as an end confirmation packet. After processing the end confirmation packet, the device triggers a Notify report of the light state synchronization sub-function to send back the final mode, color mask and brightness or speed parameters, thereby forming a consistent closed loop of "end confirmation - state synchronization - UI refresh". In addition, the present invention also specifies that after Bluetooth is disconnected and the light is off for a preset duration, it enters Deep Sleep to reduce power consumption during disconnection and idle time, and puts the sensor into a low power measurement mode to maintain motion detection. When a vibration event is detected, the device is woken up and performs parallel actions of locally lighting the preset light and notifying the event in the collaborative working mode, thereby achieving local availability and event traceability in disconnection scenarios.

[0008] Preferably, the device employs a main service and exposes write and notification features, wherein the write feature is used by the client to send control / query data packets, and the notification feature is used by the device to proactively report responses, status, events, and error information; the write feature also supports Write and WriteWithoutResponse, so that critical instructions and continuous sliding instructions can adopt different interaction strategies.

[0009] Preferably, the Header is a fixed frame header for quick synchronization and identification; the Checksum is obtained by summing the Header, Length, Command ID, Key and Data byte by byte and then performing a bitwise AND with 0xFF; when the verification fails, the device reports an error frame, which includes at least the source Command ID, source Key and error code, and the error code includes at least verification error, parameter out of bounds, current state prohibited, operation prohibited during charging, etc.

[0010] Preferably, the lighting control commands adopt a hierarchical structure of "Command ID + Key", which includes at least a lighting status setting sub-function, a lighting status synchronization sub-function, and an independent channel brightness control sub-function; wherein the lighting status synchronization sub-function is used for the client to query or the device to actively report the current lighting status, and the reported data includes at least the current mode, color mask, and current brightness / speed parameters.

[0011] Preferably, the client uses WriteWithoutResponse to send and throttle the brightness sliding process, and sends a Write Request as an end confirmation packet when the sliding ends. After the device processes the end confirmation packet, in addition to replying with ACK, it also triggers a light status synchronization report through Notify, thereby reducing the risk of client and device state drift caused by weak connection or packet loss.

[0012] Preferably, when the business logic arbitration engine detects that the device is in a charging state, it restricts or refuses to execute light control operations that conflict with charging instructions or charging management, and returns an error code "Operation prohibited while charging"; when it detects that the battery voltage is lower than the threshold, it forcibly turns off the light and refuses subsequent light-on commands, and returns an error code "Current state prohibits this operation / low battery protection" until the voltage recovers to the allowable range.

[0013] Preferably, the device has at least a pure lighting mode, a pure sensing mode, and a collaborative working mode; in the collaborative working mode, when the sensor detects a vibration event, it simultaneously triggers the local lighting of a preset light and a Notify reporting event, so that sensing-lighting-reporting form a closed loop; in the pure sensing mode, only reporting is done and the light is not lit; in the pure lighting mode, the vibration event is dominated by the client command and is not actively reported.

[0014] Preferably, after the Bluetooth connection is disconnected and the lights are off for a preset duration, the device enters Deep Sleep, and the sensor enters a low-power measurement mode to maintain motion detection. When a vibration event is detected, the device is woken up and performs parallel actions of locally lighting up the preset lights and notifying the event in the collaborative working mode, so as to achieve both low power consumption and availability during disconnection.

[0015] Based on the intelligent lighting device and its control method, the present invention can also provide an intelligent lighting control system, the system comprising: an intelligent lighting device and a client application; wherein, the intelligent lighting device is used to establish a BLE GATT communication interface and perform general frame structure parsing, business logic arbitration, lighting driving, and Notify reporting; the client application is used to establish a Bluetooth connection with the intelligent lighting device, send control / query data packets to the write feature, and receive the reporting information of the notification feature.

[0016] Preferably, the client application includes at least: 1) User interface module, used to receive user input for operations such as switching on / off, mode selection, color selection, brightness sliding, working mode switching, and sensor configuration; 2) The instruction assembly module is used to assemble control / query requests into data packets that conform to a general frame structure based on user input. The data packets include at least a frame header, length, instruction category, sub-function, parameter payload, and check field, and output the data stream to be sent. 3) Bluetooth communication interface module, used to scan and connect to smart lighting devices, and write data packets according to the interaction type by selecting the writing method. Write characteristics: write with reply for click / mode switching operations, and write without reply and throttling for brightness stepless sliding operations; 4) Status parsing and display module, used to receive and parse ACK, light status synchronization information, sensor event information and error frame information reported by smart lighting devices through Notify, and refresh the client interface, prompt the error reason and record key status changes accordingly.

[0017] Through the above system configuration, a display and consistency update logic that matches the Notify report on the device can be formed on the client side, thereby more stably realizing closed-loop consistency of "end confirmation - status synchronization - UI refresh".

[0018] (III) Beneficial Effects Compared with the prior art, the present invention provides a smart lighting device and control method based on Bluetooth communication, which has at least the following beneficial effects: 1) Unified protocol, strong scalability and good compatibility: It adopts a unified general frame structure (Header / Length / Command ID / Key / Data / Checksum) and combines it with the "Command ID+Key" hierarchical instruction set, so that new sub-functions can be extended under the existing communication and parsing framework without changing the underlying transmission and overall parsing logic, reducing version iteration costs and improving client and firmware compatibility.

[0019] 2) Improved communication reliability and traceability of anomalies: The device verifies the frame header and check field, and reports an error frame containing the source Command ID / Key and error code when the verification fails or the parameters are illegal, so as to realize "the cause of the error can be located and the anomaly can be traced back", thereby improving debugging efficiency and after-sales maintainability.

[0020] 3) Device-side arbitration forms strong constraints to avoid state conflicts: By using the business logic arbitration engine to unify the arbitration of command requests with power management status, sensor events and working modes, it can effectively avoid problems such as "conflict between charging status and light display" and "accidental light turning on when the battery is low", improve security and behavior predictability, and does not rely on the client to remember rules.

[0021] 4) Smoother continuous dimming and more consistent final state: The stepless brightness sliding adopts non-reply writing and throttling transmission, which significantly reduces the occupation of the Bluetooth link by continuous interaction and improves the smoothness of sliding dimming; at the same time, at the end of sliding, an end confirmation packet (with reply writing) is used to trigger the light status synchronization Notify report, forming a closed loop of "end confirmation - status synchronization - UI refresh", reducing the risk of UI and device status drift caused by weak connection or packet loss.

[0022] 5) Multi-working mode collaboration, adaptable to multiple scenarios: Through the configurable linkage of pure lighting mode, pure sensing mode and collaborative working mode, the same device can meet the needs of different scenarios such as "lighting only", "event monitoring and reporting only" and "sensor-triggered linkage lighting and reporting", thereby improving the product's applicability and configurability.

[0023] 6) Balancing low power consumption and availability during disconnection: By using the "disconnection and light-off timing → Deep Sleep → sensor low power measurement → vibration wake-up" chain, the power consumption of the whole device is reduced when disconnected and idle. At the same time, it can still quickly wake up and perform local lighting and event reporting when an event is triggered, realizing local availability and event traceability in disconnection scenarios, improving battery life and user experience.

[0024] 7) Enhanced system observability facilitates mass production and maintenance: The device continuously provides information such as ACK, light status synchronization, sensor events and power status through Notify, enabling the client to present the device status in real time and perform consistency verification, which also facilitates production testing, functional acceptance and subsequent fault location.

[0025] 8) By introducing modular designs such as client application instruction assembly, Bluetooth communication interface and status parsing display, it can form an end-to-end closed loop with the device's "ACK / status synchronization / event / error frame" Notify reporting mechanism, further reducing the probability of display drift and misoperation in continuous interaction scenarios, and improving system observability and maintainability. Attached Figure Description

[0026] Figure 1 A schematic diagram illustrating the overall architecture and data interaction of an intelligent lighting control system; Figure 2 This is a schematic diagram of a general data packet frame structure; Figure 3 A flowchart illustrating the multi-mode collaboration rules workflow; Figure 4 A schematic diagram of the arbitration logic for the mutual exclusion rule of the charging state. Detailed Implementation

[0027] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Please see Figure 1-4 This invention provides a smart lighting device and control method based on Bluetooth communication. To achieve reliable control and consistent feedback of the smart lighting device based on Bluetooth communication under different power supply states, different interaction intensities, and different sensor linkage requirements, this invention proposes a collaborative control technology solution of "BLE transmission layer + private protocol layer + device-side business logic arbitration layer". This solution enables lighting control, sensor events, and power management to form a strongly constrained closed loop at the device end. The client only needs to issue instructions according to the protocol and receive notifications to complete stable interaction. In one alternative implementation, in addition to the smart lighting device, a client application (such as a mobile APP) can also be set to form a smart lighting control system.

[0029] The client includes at least: a user interface for acquiring user input such as on / off states, modes, and brightness adjustments; an instruction assembly module for generating data packets according to the general frame structure; a Bluetooth communication interface for connecting to the device and sending Write / WriteWithoutResponse data packets to write feature values, and receiving Notify reports; and a status parsing and display module for parsing device-side ACKs, light status synchronization, sensor events, and error frames, and refreshing the interface. This system-side module division makes it easier to implement a consistent closed loop of "end-end confirmation—status synchronization—UI refresh". The smart lighting device establishes a GATT communication interface based on Bluetooth Low Energy (BLE), providing at least one main service and two characteristic values: the first characteristic value is used by the APP to send control / query data packets, supporting Write and WriteWithoutResponse; the second characteristic value is used by the device to actively notify and report responses, status, sensor events, and error information. For example, the device broadcast name is "OM_Light_V1", the main service UUID is 0xFFF0, the write characteristic UUID is 0xFFF1, and the notification characteristic UUID is 0xFFF2. This interface configuration allows critical controls to use writes with responses to ensure consistency, while continuous adjustment can use writes without responses to ensure smoothness, and proactive reporting from the device can be achieved through Notify.

[0030] All communication data packets between the device and the app follow a unified, general frame structure, which includes: Header, Length, Command ID, Key, Data (variable parameter payload), and Checksum. The Header is used for synchronization identification; an example of this is 0xAB. Length indicates the total number of bytes for "Command ID + Key + Data". The Data payload length is preferably controlled between 0 and 16 bytes, and based on MTU recommendations, the single packet payload should be kept within 20 bytes to ensure compatibility with common BLE implementations. The Checksum uses a bitwise AND summation check: Checksum = (Header + Length + Command ID + Key + Data byte-by-byte summation) & 0xFF. Before executing any business action, the device-side protocol parsing module first checks the Header and Checksum. If the checksum fails or the parameter is invalid, a general error frame is sent back via Notify. The error frame must at least contain the source Command ID, source Key, and error code (such as checksum error, parameter out of bounds, current state prohibited, operation prohibited during charging, etc.).

[0031] Preferably, the general error frame is reported by notification feature value, and its Data area is defined by byte offset as follows: Data[0] is the source Command ID, Data[1] is the source Key, and Data[2] is the error code; the error code can be mapped as follows: 0x01 is checksum error, 0x02 is parameter out of bounds, 0x03 is current state prohibited (low battery protection, etc.), and 0x04 is prohibited operation during charging; after reporting the error frame, the device maintains or reverts to the protection state (e.g., forced light off) and sets the corresponding protection flag.

[0032] This invention employs a hierarchical instruction set structure of "Command ID + Key". The Command ID distinguishes major instruction categories, and the Key distinguishes specific sub-functions within those categories, thereby enabling the protocol to be scalable and facilitating unified parsing and arbitration on the firmware side. Taking the lighting control category as an example, Command ID = 0x01, and it includes at least the following sub-functions: 1) Key=0x01 "Set Light Status": Data includes at least Mode, Color Mask and Param. Mode can include Off / Constant On / Breathing / Flickering, etc.; Color Mask supports multiple bits being set to 1 at the same time to achieve color mixing; Param represents brightness 0~100 in constant on mode and speed level (e.g., 1~5) in breathing / flickering mode.

[0033] 2) Key=0x02 "Lighting Status Synchronization": Used for APP to query or for the device to actively report the current lighting status. The reported data should include at least the current mode, the current color mask, and the current brightness / speed.

[0034] 3) Key=0x03 "Independent Channel Brightness Control": Used for stepless dimming scenarios, it allows setting the independent brightness values ​​(0~100 for each) of three light groups at one time, and defaults to always-on mode to achieve fine color mixing and smooth gradation.

[0035] To balance user experience and consistency with the final state, this invention specifies that the APP side distinguishes between click-based and swipe-based interactions: Click / switch / mode switching operations: Send using Write Request (with reply), and the device must reply with ACK after receiving it to ensure state synchronization; For stepless brightness sliding operations: WriteWithoutResponse is used to send data during the sliding process, and the APP controls the throttling. It is recommended to send one packet every 100ms to avoid blocking the Bluetooth channel. Preferably, the throttling interval can be configured to 50ms~300ms, more preferably 80ms~150ms, and more preferably about 100ms; when link congestion, increased retransmissions, or packet loss are detected, the APP side can dynamically increase the throttling interval and reduce the sending frequency, and the final consistency check is still performed with the end confirmation packet after the sliding ends.

[0036] End-of-swipe confirmation packet: When the swipe ends (finger lifted), the app sends another Write Request as an end-of-swipe confirmation packet to confirm the final brightness / final independent channel brightness. After receiving the end-of-swipe confirmation packet, the device, in addition to replying with an ACK, also triggers a Notify report with light state synchronization Key=0x02, sending back the final mode / color mask / brightness or speed, thus forming a consistent closed loop of "end-of-swipe confirmation - state synchronization - UI refresh", reducing the risk of client and device state drift caused by weak connections or packet loss.

[0037] The core of this invention lies in the fact that the device does not directly "parse and execute", but instead sends the parsed operation to be executed and the device's internal state to the business logic arbitration engine. After arbitration according to preset strong rules, the final execution command is output, thus avoiding conflicts between lighting control, power management, and sensor linkage.

[0038] The business logic arbitration engine shall receive at least the following inputs: The operation type (determined by Command ID + Key) and its parameters are output by the protocol parsing module; The power management module outputs battery voltage, power / charging status, and protection flags. The event signals (such as vibration / shake trigger, stillness timeout, etc.) output by the sensor management module and their configuration status; It outputs: light driver commands (mode / channel / brightness / speed), execute-allow / deny flags, and status / error messages that need to be reported via Notify.

[0039] Arbitration rules should include at least: 1) Charging mutual exclusion rule: When the device is detected to be charging, the charging indicator or charging management logic shall be given priority. Light control operations that may conflict with the charging indicator shall be restricted or refused. An error code of "operation prohibited during charging" (e.g., 0x04) shall be reported through Notify. At the same time, it is recommended that the APP only display the charging icon through the status query / reporting channel and should not interfere with the charging display through light control commands to avoid status conflicts.

[0040] 2) Low battery protection rule: When the battery voltage is detected to be lower than the preset safety threshold (example 3.3V), the arbitration engine will forcibly output a command to turn off the lights and reject subsequent commands to turn the lights on. It will return an error code (e.g. 0x03) to the APP that "this operation is prohibited in the current state" and set the protection flag until the voltage recovers to the allowable range. Preferably, the low battery threshold can be configured to 3.0V~3.6V, more preferably 3.2V~3.4V, and even more preferably 3.3V; when the voltage is lower than the threshold, in addition to rejecting the light-on command, the high-brightness / high-power light mode can also be restricted and the minimum visible indicator can be maintained. Preferably, after Bluetooth is disconnected and the light is off for a preset duration, it enters Deep Sleep, the preset duration can be configured to 1min~30min, more preferably 3min~10min, and even more preferably 5min; after entering Deep Sleep, the current of the whole device is controlled at the uA level, and the "light-on + report" is triggered by a vibration event.

[0041] 3) Multi-mode collaboration rules: The device must support at least pure lighting mode, pure sensing mode, and collaborative working mode. The arbitration engine determines the response method to sensing events based on the current working mode. Pure Light Mode: Ignores sensor vibration events; the lights are entirely controlled by APP commands and do not actively report vibration events. Pure sensor mode: Vibration does not turn on the light. When the sensor detects movement, it only reports the event via Notify. The light is off by default (unless the APP forces a light-on command). Collaborative working mode: After the sensor detects an action event, it automatically turns on the preset light and notifies the event at the same time, while the APP can still control the light at the same time.

[0042] Through the above rules, the device side forms a unified constraint on "instruction request - internal state - final execution", thereby improving system security and stability and making product behavior predictable in different usage scenarios.

[0043] In one embodiment, the power management module can obtain charging status information through the status signals of the charging management circuit. These status signals include, for example, a charging indication signal CHRG and a full charge / standby indication signal STDBY (or equivalent pin / register status), which, combined with the battery voltage sample value, form the power management status input. When executing charging mutual exclusion rules, the business logic arbitration engine preferably uses "charging status signal + battery voltage + protection flag" as a joint criterion. This prioritizes the charging indication logic during charging and restricts or rejects light control operations that may conflict with the charging indication, while simultaneously returning the corresponding error code via Notify.

[0044] The device supports wake-up and sensitivity configuration for the accelerometer (example ADXL362). Taking sensor and configuration commands as an example, Command ID=0x02, it must include at least: Key=0x01 "Gyroscope / Vibration Wake-up Configuration": Data must include at least the wake-up switch, ambient mode, and hold time (seconds); the ambient mode must include at least three levels: calm / normal / violent shaking, and can be mapped to different acceleration thresholds (examples 50mg, 150mg, 250mg) to adapt to different triggering requirements such as light touch, normal picking, and vigorous shaking; the hold time is used to define the duration of the light after wake-up.

[0045] Key=0x80 "Sensor Event Reporting": After the device detects an action, it actively Notifies and reports the event type. The event type must include at least "Vibration / Shake Trigger" and "Automatic Shutdown After Stillness Timeout".

[0046] In collaborative working mode, sensor events will trigger the parallel actions of "locally lighting up preset lights + event notification reporting"; in pure sensing mode, only reporting is done without lighting up; in pure lighting mode, no active reporting is performed, thus realizing configurable linkage of the same hardware capabilities in different modes.

[0047] Preferably, the sensor and configuration instructions can further define a "system operating mode setting" sub-function for configuring pure lighting mode, pure sensing mode, and collaborative operating mode; it can use an independent key (e.g., Key=0x02), or it can be combined with the wake-up configuration under the same key and distinguished by the Data field. The operating mode values ​​may include: 0x01 for pure lighting mode, 0x02 for pure sensing mode, and 0x03 for collaborative operating mode.

[0048] An example of a device information and power management command is Command ID=0x03. The device must support at least: Key=0x01 "Get Device Status": The APP sends a query command; Key=0x81 “Device Status Reply / Report”: The device replies with battery voltage (mV, little-endian), charging status (not charging / charging / fully charged) and error / protection flags (such as low battery protection to prevent lights from turning on); and can actively report when the charging status changes.

[0049] Furthermore, the protocol can define firmware behavior for "power saving display when charging is fully complete" (such as a green light that stays on for the first 10 minutes and then turns off to enter power saving mode), and stipulates that as long as the charger is not unplugged, the device should report the "fully charged" status to the APP, so that the APP UI remains consistent without needing to care whether the indicator light is off.

[0050] To reduce idle power consumption during disconnection and improve usability in disconnection scenarios, this invention specifies a low-power strategy: when Bluetooth is disconnected and the light is off for a preset duration (5 minutes in the example), the main controller enters Deep Sleep; simultaneously, the sensor enters Measurement Mode to maintain ultra-low power action detection, keeping the overall current at the uA level. Subsequently, when a vibration event is detected, the device wakes up from Deep Sleep and performs the parallel actions of "lighting up the preset light + notifying to report the vibration event" in collaborative working mode, achieving a closed-loop chain of "disconnection sleep—vibration wake-up—local availability—event traceability".

[0051] To implement the above control method, the present invention also provides a smart lighting device based on Bluetooth communication, comprising at least: Bluetooth communication module: Implements BLE radio frequency and GATT services, and is responsible for data packet transmission and reception; Protocol parsing module: Parses the general frame structure, extracts Command ID, Key, and Data, and performs verification; Business logic arbitration module: Connects to the protocol parsing module, power management module, and sensor management module. Arbitrates operations based on rules such as charging mutual exclusion, low battery protection, and multi-mode collaboration, and outputs the final execution command. Lighting driver module: Generates corresponding drive signals according to the final executed command to achieve constant brightness / breathing / flickering / color mixing / independent channel brightness; Power management module: Monitors battery voltage and charging status and outputs protection flags; Sensor management module: manages accelerometer thresholds / environmental modes and generates events; Memory and processor: Stores configurations such as operating mode, sensitivity, and hold time, and runs the above protocol parsing and arbitration logic.

[0052] The device is configured to: trigger a Notify report of the light status synchronization Key=0x02 after the confirmation packet arrives at the sliding end; and enter Deep Sleep when the disconnection and light-off conditions are met and the device can be woken up by a sensor event, thereby supporting the feasible implementation of two key features: "interaction consistency closed loop" and "low-power wake-up linkage".

[0053] In one optional implementation, in addition to the device-side module, a client application (e.g., a mobile APP) is also provided to constitute the intelligent lighting control system. The client application includes a user interface module, an instruction assembly module, a Bluetooth communication interface module, and a status parsing and display module. The user interface module is used to acquire operational inputs such as switch, mode, color, brightness sliding, working mode switching, and sensor configuration; the instruction assembly module maps the operational inputs to a combination of "instruction category + sub-function key + parameter payload," and generates a data packet to be sent according to a general frame structure; the Bluetooth communication interface module writes the data packet into the device-side write feature, wherein for switch / mode switching instructions, a write with reply is used to obtain ACK, and for brightness stepless sliding instructions, a write without reply is used and the transmission frequency is throttled, and a write with reply is sent once at the end of the sliding as an end confirmation packet; the status parsing and display module receives information reported by the device-side notification feature, parses it to obtain ACK, lighting status synchronization information, sensor events, and error codes, and updates the final displayed mode, color mask, and brightness / speed parameters after receiving the lighting status synchronization report corresponding to the end confirmation packet, thereby ensuring that the client-side displayed state is consistent with the actual state of the device.

[0054] Furthermore, when the device refuses to execute a command due to charging mutual exclusion or low battery protection, the device will report an error frame containing the source command information and error code via Notify. After parsing, the client can display reasons such as "operation is prohibited during charging" or "low battery protection / current state prohibition", and prevent the interface from continuing to send invalid commands, thereby improving user experience and system stability.

[0055] Example 1: System and Hardware Composition The intelligent lighting device uses a BLE main control chip to implement GATT service, and the device broadcast name can be "OM_Light_V1". The device includes three sets of LEDs (e.g., emerald green / pink / ice blue), and is connected to sensors (e.g., a three-axis accelerometer) and charging / battery voltage detection circuits. The device establishes a main service (e.g., 0xFFF0) and sets write characteristics (e.g., 0xFFF1) for the APP to send control commands, and sets notification characteristics (e.g., 0xFFF2) for the device to report status, events, and error information.

[0056] In one example implementation, the device-side BLE controller can be a chip supporting BLE 5.1 ​​(e.g., OM6621Ex or a similar chip), the sensor can be a triaxial accelerometer (e.g., ADXL362 or a similar device), and the charging management circuit can be a linear charging management chip (e.g., TP4056 or a similar chip). The above devices are only used to illustrate the feasibility of the invention, and the invention does not limit the specific chip model.

[0057] Example 2: General Frame Structure and Verification All control and query commands sent by the app to the device use a unified, universal frame structure: Header, Length, Command ID, Key, Data, and Checksum. The Header can be fixed at 0xAB for synchronization identification; Length represents the total number of bytes for Command ID, Key, and Data; the Checksum is calculated by bitwise ANDing the sum with 0xFF. The device-side protocol parsing module first verifies the Header and Checksum. If the verification fails, it sends back an error frame via Notify with the error code "Checksum Error".

[0058] For ease of understanding, in an example scenario, when a user selects a specific lighting effect on the client, the client can assemble and send data packets according to a general frame structure. For example, the frame header is 0xAB, followed by a length field, a category of lighting control commands, a sub-function for setting the lighting status, and parameter bytes such as mode / color / speed. After successful verification, the device parses the data to obtain the operation type corresponding to the Command ID+Key. The arbitration engine confirms that there is no charging conflict and the battery level meets the threshold before driving the light to execute. If the device is charging and the operation conflicts with the charging indicator, it will be rejected according to the charging mutual exclusion rule, and an error frame containing the source Command ID, source Key, and error code (e.g., "Operation prohibited while charging") will be returned via Notify. The above is only an example; the specific parameter bytes can be configured according to the actual protocol definition.

[0059] Example 3: Lighting Control and Mixing / Stepless Dimming When the app selects a constant / breathing / blinking mode, it sends parameters via lighting control commands (e.g., Command ID=0x01): Mode, Color Mask, and brightness or speed level. The color mask supports multiple bits being set to 1 simultaneously to achieve color mixing; the brightness range is, for example, 0~100. Furthermore, for fine-tuned color mixing, three brightness values ​​can be set at once via an independent channel brightness control sub-function, and the device outputs the corresponding PWM duty cycle in constant-on mode.

[0060] Example 4: Sensor wake-up configuration and event reporting The app allows configuration of vibration wake-up switch, ambient mode, and hold time. Ambient mode can correspond to different acceleration thresholds, such as: 50mg for calm environment, 150mg for normal environment, and 250mg for violent shaking; hold time is measured in seconds and is used to determine the duration of light illumination after wake-up. When the device detects a vibration / shake trigger, it reports the sensor event type (such as vibration trigger, inactivity timeout, etc.) via Notify.

[0061] Example 5: Multiple Working Modes and Collaborative Logic The device supports at least three operating modes: Pure Light Mode: Ignores sensor triggers and only executes the APP's light commands; Pure sensing mode: Sensor triggers only report the signal and do not trigger local light illumination; Collaborative working mode: When the sensor triggers, the preset light is turned on and the event is reported. The APP can still control the light at any time.

[0062] The device-side business logic arbitration engine determines whether to trigger local lighting actions based on the pattern of the sensor event.

[0063] Example 6: Power Management, Charging Exclusion and Low Battery Protection The app can query battery voltage and charging status through device information and power management commands; the device response includes voltage (little-endian mV), charging status field (not charging / charging / fully charged) and protection flag field.

[0064] When charging is detected, the device controls the charging indication logic according to the charging mutual exclusion rule and refuses to execute light commands that conflict with the indication, returning the error code "Operation prohibited while charging" via Notify.

[0065] When the detected voltage is below the threshold (e.g., 3.3V), the device enters low battery protection: forcibly turns off the light, rejects the light-on command, and returns the error code "Current state prohibits this operation / low battery protection".

[0066] Example 7: Interaction Strategy and Low-Power Sleep For click / switch / mode switching operations, the app uses write request to ensure state synchronization; for stepless brightness swiping, write without response is used, and the sending frequency is controlled by throttling (e.g., one packet every 100ms). After swiping ends, write request is sent again to confirm the final brightness.

[0067] When Bluetooth is disconnected and the lights are off for a certain period of time (e.g., 5 minutes), the device enters deep sleep to reduce overall power consumption and keep the sensors in low-power measurement mode to support wake-up.

[0068] Example 7: Bluetooth Communication Protocol Constraints and Interoperability Interface Specifications In a preferred embodiment, to ensure interoperability, state consistency, and anomaly traceability between the intelligent lighting device and the client application, this embodiment provides the following protocol-based constraints regarding the Bluetooth communication interface, data frame format, interaction strategy, error handling, power supply, and hardware constraints. It should be understood that the following field definitions, example values, and thresholds are only used to illustrate the implementable methods of this invention and do not constitute a limitation on the scope of protection of this invention; provided that the same data structure and control logic are satisfied, the above values ​​are allowed to be equivalently replaced or parameterized.

[0069] 1. GATT Service and Feature Value Interface Specifications Preferably, the smart lighting device establishes a GATT service based on Bluetooth Low Energy (BLE), which includes at least write characteristic values ​​and notification characteristic values: (1) The write feature value is used to receive data packets sent by the client, and supports two modes: write request with response and write without response. (2) Notification feature value is used by the device to actively report response, status, event and error information to the client, and pushes it using the Notify mechanism.

[0070] More preferably, the device can be discovered and paired by broadcasting a name and / or service UUID. The broadcast name, service UUID, and characteristic UUID can be stored as parameter configuration items in firmware or memory, and the client scans and connects according to the same criteria.

[0071] 2. General frame structure and byte order / length constraints Preferably, the uplink data packet carried by the written feature value adopts a general frame structure, which includes at least: frame header, length, command ID, sub-function key, parameter payload data, and checksum field.

[0072] in: (1) The Header is used for frame synchronization identification; the Length is used to indicate the effective byte length or payload length from the Command ID to the Checksum. (2) Command ID is used to distinguish macro-level business categories, Key is used to distinguish specific operations within the same category; Data is used to carry parameters; (3) Multi-byte numerical parameters (such as battery voltage, timing value, etc.) are preferably encoded using fixed byte order (e.g., little-endian), and the client and device should be consistent with each other; (4) The effective payload length of a single packet is preferably controlled by the BLE MTU constraint. When it is necessary to transmit longer data, packet splitting or multi-frame mechanism can be used.

[0073] 3. Verification Mechanism and Abnormal Frame Handling Preferably, the device verifies the Header and Checksum before entering the business processing, and performs a validity check on the range of Length, Command ID, Key and Data parameters. When the verification fails or the parameter is invalid, the corresponding control action is not executed. Instead, an error frame is reported by notifying the feature value, forming a traceable abnormal closed loop.

[0074] Preferably, the Data area of ​​the error frame includes at least: Data[0] as the source Command ID, Data[1] as the source Key, and Data[2] as the error code; the error code can be mapped as follows: 0x01: Verification error; 0x02: Parameter out of bounds / illegal; 0x03: This operation is currently disabled (e.g., low battery protection). 0x04: Operation is prohibited while charging (charging mutual exclusion trigger).

[0075] More preferably, the device keeps the light status unchanged after reporting an error frame, or forcibly turns off the light according to the protection rules, in order to avoid state drift caused by abnormal frames.

[0076] 4. Closed-loop synchronization of instruction hierarchy and state Preferably, the client uses write with reply for critical operations such as "click / mode switching" to obtain ACK from the device; and uses write without reply for continuous operations such as "brightness stepless sliding" to improve the smoothness of interaction, and the client performs throttling of the transmission.

[0077] Preferably, the throttling transmission interval can be configured to be 50ms to 300ms, more preferably 80ms to 150ms, and more preferably about 100ms.

[0078] More preferably, to ensure the consistency of the final state after continuous sliding ends, the client sends a write-with-reply packet as an end confirmation packet at the end of the sliding; after processing the end confirmation packet, the device, in addition to returning ACK, also triggers a "light status synchronization" report by notifying feature values ​​to send back the final mode, color mask and brightness / speed parameters. After receiving the report, the client refreshes the interface display, thus forming a consistent closed loop of "end confirmation - status synchronization - interface update".

[0079] In one example, the Key for the light status synchronization sub-function can be 0x02 or its equivalent identifier field.

[0080] 5. Working mode configuration and sensor event linkage Preferably, the system supports at least three modes: pure lighting mode, pure sensing mode, and collaborative working mode. In collaborative working mode, when the sensor detects an action event, it triggers the parallel execution of "locally lighting up preset lights + event reporting"; in pure sensing mode, only reporting is performed without lighting up; in pure lighting mode, the lights are completely controlled by the client and the sensing event can be ignored.

[0081] More preferably, the working mode setting can be achieved by combining Command ID and Key, where Key can be 0x01 or its equivalent identifier field, and the mode value can correspond to three states: pure light / pure sensing / collaboration.

[0082] Preferably, the trigger threshold of sensor events can be set in stages, for example, the motion acceleration threshold can be set to the first level, the second level, and the third level. Example thresholds can be 50mg, 150mg, and 250mg (or equivalent units / conversion values), and the holding time (e.g., 1s to 10s) can be set to perform de-jittering and false triggering suppression. The above thresholds and holding times can be parameterized and stored on the device.

[0083] 6. Power Management and Hardware Constraints Preferably, the device is equipped with a power management module to collect battery voltage and obtain charging status signals as input for business logic arbitration.

[0084] (1) Low battery protection: When the battery voltage is detected to be lower than the threshold, the device will forcibly turn off the light and refuse to execute the light-on / high power consumption light effect command, and will display an error code indicating "Current state prohibited / low battery protection". Preferably, the voltage threshold can be configured to 3.0V to 3.6V, more preferably 3.2V to 3.4V, and more preferably 3.3V.

[0085] (2) Charging mutual exclusion: When the device is charging and the light control request may conflict with the charging indication logic, the device refuses to execute the corresponding light instruction according to the charging mutual exclusion rule and prompts "Operation is prohibited during charging" through the error code.

[0086] More preferably, the charging indicator light can be directly driven and controlled by the hardware circuit (e.g., the indicator light is turned on and off by the status signal of the charging management circuit). The client application displays the status on the interface without forcibly interfering with the hardware charging indicator logic. If the client still issues a light control command that conflicts with the charging indicator, the device will arbitrate and reject it and report the corresponding error code to ensure that hardware constraints take precedence.

[0087] 7. Disconnection low-power strategy and wake-up logic Preferably, when the Bluetooth connection is lost and the lights are off for a preset period of time, the device enters a deep sleep mode to reduce power consumption during disconnection and idle time, while the sensor enters a low-power measurement mode to maintain motion detection.

[0088] Preferably, the preset duration can be configured to be 1 minute to 30 minutes, more preferably 3 minutes to 10 minutes, and more preferably about 5 minutes.

[0089] More preferably, when the sensor detects an action event, the device wakes up from deep sleep and performs local lighting of preset lights and / or reporting of action event information in collaborative working mode, thereby achieving local availability and event traceability in disconnection scenarios.

[0090] Through the above-described protocol constraint implementation, the client and device can maintain consistent frame parsing and state loop under different Bluetooth link qualities, different power states, and different interaction frequencies. Furthermore, anomalies can be quickly located by error frames and error codes, meeting the requirements for engineering implementation and verifiability.

[0091] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for controlling intelligent lighting equipment based on Bluetooth communication, characterized in that, include: S1: The intelligent lighting device establishes a GATT communication interface based on Bluetooth Low Energy, sets a first characteristic value to receive data packets sent by the client, and sets a second characteristic value to actively notify and report to the client; S2: Receive data packets using a general frame structure through the first feature value, and verify the frame header and check field; S3: After successful verification, parse the Command ID and Key fields of the data packet to determine the type of operation to be executed; S4: Arbitrate the operation type to be executed with the current sensor events and power management status of the device by inputting it into the business logic arbitration engine, and output the final execution command; S5: Drive the light module to execute according to the final execution command, and report the response, status, event or error information to the client through the second feature value.

2. The method for controlling intelligent lighting equipment based on Bluetooth communication according to claim 1, characterized in that, The general frame structure includes Header, Length, Command ID, Key, Data, and Checksum in sequence, where Header is a fixed frame header and Length represents the total number of bytes of Command ID, Key, and Data.

3. A method for controlling intelligent lighting equipment based on Bluetooth communication according to claim 1 or 2, characterized in that, The Checksum is obtained by summing the Header, Length, Command ID, Key and Data byte by byte and then performing a bitwise AND operation with 0xFF; when the verification fails, the device reports an error frame containing the source Command ID, source Key and error code via Notify.

4. The method for controlling intelligent lighting equipment based on Bluetooth communication according to claim 1, characterized in that, The business logic arbitration engine includes charging mutual exclusion rules: when the device is detected to be charging, it restricts or refuses to execute light control operations that conflict with the charging indication logic, and reports an error code that prohibits operation during charging to the client.

5. The method for controlling intelligent lighting equipment based on Bluetooth communication according to claim 1, characterized in that, The business logic arbitration engine includes a low battery protection rule: when the battery voltage is detected to be lower than a preset threshold, the light is forcibly turned off and subsequent light-on commands are rejected, and an error code prohibiting this operation is reported to the client; in one embodiment, the preset threshold is 3.3V.

6. The method for controlling intelligent lighting equipment based on Bluetooth communication according to claim 1, characterized in that, The device features a pure lighting mode, a pure sensing mode, and a collaborative working mode. In the collaborative working mode, when the sensor detects a vibration event, it triggers the local lighting of a preset light and simultaneously reports the vibration event via Notify.

7. The method for controlling intelligent lighting equipment based on Bluetooth communication according to claim 1, characterized in that, For stepless brightness sliding operation, the client sends control data packets to the first feature value and performs throttling during the sliding process using the WriteWithoutResponse method, and it is recommended to send one packet at an interval of about 100ms; at the end of the sliding, a Write Request is sent as an end confirmation packet to confirm the final value. After responding to the end confirmation packet, the device reports the current light status through the Notify light status synchronization sub-function; wherein the key of the light status synchronization sub-function is 0x02, and the reported data includes at least the current mode, the current color mask, and the current brightness / speed parameters.

8. The method for controlling intelligent lighting equipment based on Bluetooth communication according to claim 1, characterized in that, The device enters Deep Sleep after Bluetooth is disconnected and the lights are off for a preset duration, and puts the sensors into measurement mode to maintain low-power motion detection; when a vibration event is detected, it wakes up from Deep Sleep and performs local lighting of a preset light in collaborative working mode and reports the event via Notify; in one embodiment, the preset duration is 5 minutes.

9. A Bluetooth-based smart lighting device for performing the method described in claims 1-8, characterized in that, include: Bluetooth communication module, protocol parsing module, business logic arbitration module, lighting driver module, power management module, sensor management module, as well as memory and processor; The Bluetooth communication module is configured to establish a GATT communication interface based on Bluetooth Low Energy, set a write feature to receive data packets sent by the client, and set a notification feature to actively notify the client of reported responses, statuses, events, or error information. The protocol parsing module is used to parse data packets using a general frame structure. The general frame structure includes at least a frame header, length, command ID, sub-function key, parameter payload data, and checksum field. After the check passes, it outputs the type of operation to be executed and its parameters. The business logic arbitration module is used to arbitrate the type of operation to be executed and its parameters with the battery voltage / charging status output by the power management module and / or the sensor events output by the sensor management module, and outputs the final execution command or refuses to execute and outputs an error code according to the preset arbitration rules; wherein the arbitration rules include at least the charging mutual exclusion rule and the low power protection rule; The light driving module is used to control the light output according to the final execution command; Furthermore, the intelligent lighting device is configured as follows: For continuous control data packets for stepless brightness adjustment, it supports receiving and executing continuous adjustment in a non-reply write mode. After receiving the end confirmation packet sent in a reply write mode, in addition to replying with ACK, it also reports the current light status according to the light status synchronization sub-function through the notification feature to achieve final state consistency. After the Bluetooth connection is disconnected and the light is off for a preset duration, the system enters deep sleep mode and puts the sensor management module into low-power measurement mode to maintain motion detection. When a vibration event is detected, the system wakes up and outputs a notification message to locally light up a preset light and / or report the vibration event.

10. A smart lighting control system based on Bluetooth communication, characterized in that, include: The intelligent lighting device and client application as described in claim 9; The client application includes at least: The user interface module is used to receive user input for switch, mode, color and / or brightness adjustment. An instruction assembly module is used to assemble control / query requests into data packets conforming to the general frame structure based on the input. A Bluetooth communication interface module is used to establish a connection with the smart lighting device, write the data packet to the write feature, and receive notification reports from the notification feature; The status parsing and display module is used to parse the ACK, light status synchronization information, sensor event information and / or error code information in the notification report and refresh the display. Furthermore, the client application is configured to: send continuous adjustment data packets and perform throttling in a non-reply write mode during the stepless brightness sliding process, and send an end confirmation packet in a reply write mode at the end of the sliding process; the intelligent lighting device is configured to report the current lighting status through the lighting status synchronization sub-function after processing the end confirmation packet, so as to form a consistent closed loop of "end confirmation - status synchronization - interface update".

Images