Broadcasting method, apparatus and storage medium

Abstract

The application discloses a broadcast method, a device and a storage medium, and relates to the technical field of wireless communication networks. The disclosed method comprises the following steps: creating an independent periodic timer for each type of broadcast instance according to a broadcast time interval corresponding to each type of broadcast instance, wherein the broadcast instance comprises a first type of broadcast instance conforming to a Matter standard protocol specification and a second type of broadcast instance conforming to a user-defined protocol; when the periodic timer detects that the broadcast time interval of the corresponding broadcast instance is reached, sending the corresponding broadcast instance identifier to a message queue to obtain a broadcast time sequence; and based on the broadcast time sequence, sequentially scheduling the broadcast data corresponding to the broadcast instance identifier for broadcasting. Through the technical scheme of the application, the problem that a single radio frequency is difficult to be compatible with multiple types of protocol broadcasting is solved, and the broadcast of multiple types of protocols through a single radio frequency is realized.

Description

Technical Field

[0001] This application relates to the field of wireless communication network technology, and in particular to broadcasting methods, apparatus and storage media. Background Technology

[0002] Currently, smart home devices can broadcast using a single BLE (Bluetooth Low Energy) radio frequency to perform operations such as device discovery, network pairing, and firmware upgrades. However, a single BLE radio frequency typically only supports broadcast instances of a single protocol type. When smart home devices simultaneously require broadcast instances using different protocol types, the single BLE radio frequency cannot meet the broadcast requirements of multiple different protocol types at the same time. Summary of the Invention

[0003] The main purpose of this application is to provide a broadcasting method, apparatus and storage medium, which aims to solve the technical problem that the current single BLE radio frequency cannot simultaneously meet the broadcasting requirements of multiple broadcasting instances of different types of protocols.

[0004] To achieve the above objectives, this application proposes a broadcasting method, comprising: Based on the broadcast time interval corresponding to each type of broadcast instance, an independent periodic timer is created for each type of broadcast instance. The broadcast instances include the first type of broadcast instances that conform to the Matter standard protocol specification and the second type of broadcast instances that conform to the user-defined protocol. When the broadcast time interval corresponding to the broadcast instance is detected by the periodic timer, the corresponding broadcast instance identifier is sent to the message queue to obtain the broadcast timing. Based on broadcast timing, broadcast data corresponding to broadcast instance identifiers are scheduled to be broadcast sequentially.

[0005] In addition, to achieve the above objectives, this application also proposes a broadcasting device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the broadcasting method as described above.

[0006] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the broadcast method as described above.

[0007] The one or more technical solutions proposed in this application have at least the following technical effects: By creating independent periodic timers for the first type of broadcast instance conforming to the Matter specification and the second type of broadcast instance of the user-defined protocol, the triggering rhythm of each broadcast instance is precisely controlled by its corresponding timer, thereby constructing an asynchronous triggering mechanism for multiple broadcast instances at the software level; when the periodic timer expires, only the corresponding broadcast instance identifier is sent to the message queue to generate the broadcast sequence; based on the broadcast sequence, the corresponding broadcast data is scheduled sequentially, and the broadcast requirements of the first type of broadcast instance of the Matter protocol and the second type of broadcast instance of the user-defined protocol can be simultaneously met on a single BLE radio frequency in a time-division multiplexing manner, thereby solving the problem that a single radio frequency is difficult to be compatible with the broadcast of multiple types of protocols without expanding the hardware broadcast capabilities, and realizing the broadcast of multiple types of protocols through a single radio frequency. Attached Figure Description

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

[0009] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a flowchart illustrating the first embodiment of the broadcasting method of this application. Figure 2 This is a schematic diagram of the system architecture of the broadcast method of this application; Figure 3 This is a schematic diagram of the broadcast timing of this application.

[0011] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0013] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0014] Currently, smart home devices can broadcast via a single BLE radio frequency to perform operations such as device discovery, network configuration, and firmware upgrades. However, a single BLE radio frequency typically only supports broadcast instances of a single protocol type. When smart home devices simultaneously require broadcast instances using different protocol types, the single BLE radio frequency will be unable to meet the broadcast requirements of multiple different protocol types at the same time.

[0015] To address the aforementioned shortcomings, this application proposes a broadcasting method. The main technical solution includes: creating an independent periodic timer for each type of broadcast instance based on the broadcast time interval corresponding to each type of broadcast instance; wherein the broadcast instances include a first type of broadcast instance conforming to the Matter standard protocol specification and a second type of broadcast instance conforming to a user-defined protocol; when the broadcast time interval of the corresponding broadcast instance is detected by the periodic timer, sending the corresponding broadcast instance identifier to the message queue to obtain the broadcast timing; and scheduling the broadcast data corresponding to the broadcast instance identifiers for broadcasting in sequence based on the broadcast timing.

[0016] By creating independent periodic timers for the first type of broadcast instances conforming to the Matter specification and the second type of broadcast instances conforming to user-defined protocols, the triggering rhythm of each broadcast instance is precisely controlled by its corresponding timer, thus constructing an asynchronous triggering mechanism for multiple broadcast instances at the software level. When the periodic timer expires, only the corresponding broadcast instance identifier is sent to the message queue to generate a broadcast sequence. Based on this broadcast sequence, the corresponding broadcast data is scheduled sequentially. The broadcast requirements of the first type of broadcast instances of the Matter protocol and the second type of broadcast instances of the user-defined protocol can be simultaneously met on a single BLE radio frequency in a time-division multiplexing manner. This solves the problem that a single radio frequency is difficult to be compatible with broadcasting of multiple types of protocols without expanding the hardware broadcasting capabilities, and realizes the broadcasting of multiple types of protocols through a single radio frequency.

[0017] It should be noted that the execution subject of this embodiment is a smart home device, which has its own BLE radio frequency, and the broadcast method of this application operates on this BLE radio frequency. The smart home device can execute the broadcast method of this application through its own BLE radio frequency to achieve communication with the Bluetooth terminal device, so that the Bluetooth terminal device can discover the smart home device and achieve the purpose of network pairing with the smart home device; it can also execute the broadcast method of this application through its own BLE radio frequency to enable the manufacturer's proprietary application to perform operations such as device identification, parameter configuration or firmware upgrade.

[0018] The aforementioned smart home devices can be those with their own low-cost, single BLE radio frequency, including but not limited to the following categories: Intelligent lighting equipment: such as intelligent ceiling lights, intelligent light bulbs, and light strip controllers.

[0019] Smart electrical devices: such as smart sockets, smart switches, and smart power strips.

[0020] Environmental sensing devices: such as temperature and humidity sensors, air quality detectors, and light sensors.

[0021] Security equipment: such as smart door locks, door and window sensors, water immersion sensors, and smoke detectors.

[0022] Home appliances: such as air conditioners, humidifiers, dehumidifiers, and air purifiers.

[0023] Control devices: such as curtain motors, window openers, and infrared repeaters.

[0024] Energy management equipment: such as smart meters and energy consumption monitoring sockets.

[0025] The aforementioned Bluetooth terminal devices can be various devices with BLE scanning and connection capabilities, including but not limited to: User terminal devices: smartphones, tablets, and wearable devices such as smartwatches.

[0026] Smart home control devices: smart speakers, smart central control screens, home gateways.

[0027] Manufacturer debugging equipment: production line programming fixtures, on-site debugging tools, OTA upgrade boxes.

[0028] Other smart home devices: smart door locks and smart sensors with BLE scanning capabilities.

[0029] Based on this, embodiments of this application provide a broadcasting method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the broadcasting method of this application. In this embodiment, the broadcasting method includes steps S10 to S30: Step S10: Based on the broadcast time interval corresponding to each type of broadcast instance, create an independent periodic timer for each type of broadcast instance. The broadcast instances include a first type of broadcast instance that conforms to the Matter standard protocol specification and a second type of broadcast instance that conforms to a user-defined protocol.

[0030] A broadcast instance refers to an entity object abstracted at the software logic level that possesses complete broadcast behavior capabilities. It is not merely a piece of broadcast data, but a collection of structures containing broadcast data content, scan response data, broadcast time interval, Bluetooth address type, running status flags, and related mutex locks. It is the smallest unit of scheduling.

[0031] The broadcast interval refers to the length of time between two consecutive broadcast transmissions initiated by a single broadcast instance. This broadcast interval determines the frequency at which smart home devices send broadcast data per unit of time. In Bluetooth Low Energy technology, a shorter broadcast interval means faster device discovery but relatively higher power consumption; a longer interval is beneficial for reducing power consumption but may prolong discovery time. The Matter standard protocol typically requires a shorter broadcast interval, such as 20 to 60 milliseconds, during the network discovery phase, while user-defined protocols, such as vendor-specific protocols, may tolerate longer broadcast intervals, such as 200 to 1000 milliseconds. In other words, the broadcast interval used by different types of broadcast instances will differ.

[0032] A periodic timer, which can be a software or hardware timing device, automatically generates an interrupt signal or callback event after a set broadcast interval expires, sending the corresponding broadcast instance identifier to the message queue. In this solution, it is not used to directly broadcast data, but rather to trigger broadcast requests at precise times. Each type of broadcast instance creates an independent periodic timer, and each periodic timer runs independently without interference. It should be noted that in related technologies, a timeline needs to be planned in advance, and a time period needs to be pre-allocated to each broadcast packet. The timer's function is to periodically read broadcast data packets from the message queue for transmission, without distinguishing between broadcast data packets of different protocol types. However, this application does not pre-allocate a timeline; each broadcast instance has an independent periodic timer. When the timer expires, it sends the corresponding broadcast instance identifier to the message queue and triggers a scheduling event. The function of the periodic timer in this application is to periodically send the broadcast instance identifier to the message queue.

[0033] Type 1 broadcast instances refer to broadcast instances carrying Matter standard protocol specification data. Their main function is to broadcast specific information required for Matter device network configuration, such as manufacturer identification codes, product identification codes, device types, and network configuration authentication information, enabling the Matter controller to discover and configure devices based on the first broadcast data. According to the security requirements of the Matter standard protocol, such broadcast instances must use random static addresses to protect user privacy, and their broadcast intervals must follow the fast and slow broadcast rhythms specified in the protocol. The manufacturer identification code, also known as the supplier ID, is used in the first broadcast data to indicate the device's origin, allowing the Matter controller to identify the device's brand. The product identification code, also known as the product ID, is defined by the manufacturer; different smart home devices have corresponding product identification codes, which help the Matter controller load the corresponding device description information and drivers. Device type information is an enumeration value predefined by the Matter specification to describe the device's main functions. For example, the device type information for a smart bulb might correspond to a specific value, while that for a smart door lock might correspond to another value, allowing the Matter controller to quickly understand the device's purpose. Network configuration authentication information is used to distinguish multiple identical devices of the same manufacturer and model during the network configuration process. When a user scans a QR code using a mobile app or manually enters a setup code, they are actually specifying this network configuration authentication information. This ensures that even when multiple identical devices exist, the user can accurately connect to the target Bluetooth terminal device for network configuration, avoiding misoperation.

[0034] The second type of broadcast instance refers to a broadcast instance carrying user-defined protocols, i.e., vendor-specific protocol data. This second broadcast data includes at least a vendor-specific protocol identifier, device serial number, and debugging information to enable vendor-specific applications to identify devices, configure parameters, or upgrade firmware. These instances typically use public addresses for easy identification and unified management by vendor tools, and their broadcast intervals and message formats are defined by the vendor. The vendor-specific protocol identifier is a custom string used by the vendor to identify its proprietary protocol version. For example, the vendor can place a specific four-byte character combination at the beginning of the broadcast data. This allows the vendor's dedicated debugging tools to quickly filter out devices that do not conform to its protocol, preventing accidental connection to other devices in complex environments. The device serial number is a unique string or numeric code burned into the device by the vendor during the manufacturing process; it acts like the device's identification number, sent in the private broadcast, allowing the vendor's maintenance personnel to quickly and accurately locate specific devices on-site. Debugging information refers to various internal status and diagnostic data generated during device operation; for example, it can include the current firmware version number, hardware self-test results, error log codes, raw sensor readings, remaining memory size, etc. Vendor-proprietary applications refer to dedicated software tools developed and used by equipment manufacturers, rather than general-purpose apps for end users; examples include automated testing software on production lines, field debugging apps for engineers, or management tools for batch firmware upgrades. These applications identify and connect to devices by scanning second-broadcast data.

[0035] It should be noted that the types of broadcast instances in this scheme are not limited to the first type of broadcast instance and the second type of broadcast instance, but may also include other types of broadcast instances.

[0036] In one alternative approach, the periodic timer can be a software timing device. Specifically, for a first-type broadcast instance, the system reads its configured broadcast time interval, for example, 30 milliseconds, and then calls the system's Timer Creation API to create an independent periodic timer. During creation, the system assigns a unique identifier to this periodic timer and binds its callback function to the processing logic of the first-type broadcast instance. For a second-type broadcast instance, the system reads its configured broadcast time interval, for example, 500 milliseconds, and similarly calls the system's Timer Creation API to create an independent periodic timer, whose callback function is bound to the processing logic of the second-type broadcast instance. The two periodic timers have independent timing contexts in the system kernel and will not experience timing drift due to each other's interrupt handling.

[0037] In another alternative approach, the periodic timer can be a hardware timing device. Specifically, in embedded systems with extremely limited resources or requiring extremely high timing accuracy, the system directly configures the hardware timer inside the microcontroller. The system first enables the clock source of the hardware timer and sets its counting mode to periodic automatic reload. For the first type of broadcast instance, the system configures the broadcast interval of the hardware timer and registers the timeout interrupt service function for this periodic timer. When an interrupt occurs, the interrupt service function marks the trigger flag of the first type of broadcast instance within a very short time. For the second type of broadcast instance, the system utilizes different channels of the same hardware timer, or configures the broadcast interval of another independent hardware timer and registers the corresponding interrupt service function. The hardware timer operates with its independent counting logic, unaffected by delays in the system main loop or operating system task scheduling, thus improving trigger accuracy.

[0038] Step S20: When the broadcast time interval of the corresponding broadcast instance is detected by the periodic timer, the corresponding broadcast instance identifier is sent to the message queue to obtain the broadcast timing.

[0039] A broadcast instance identifier can be an integer value or an enumeration to refer to a specific broadcast instance. The broadcast instance identifiers for Type 1 and Type 2 broadcast instances differ. It does not contain broadcast data itself; it serves only as a token to communicate the intent of who should send the broadcast between different modules of the system, such as timer callback functions and scheduled tasks.

[0040] A message queue is a data structure used for inter-process or inter-thread communication, following a first-in, first-out (FIFO) principle. In this scheme, it acts as a buffer pool, connecting the timer context and the background processing context. Message queues feature asynchronous decoupling; the sender only needs to put broadcast data into the message queue and return without waiting for the receiver to process it; the receiver then retrieves data from the message queue for processing at the appropriate time. Here, the sender can be a callback function of a periodic timer, and the receiver can be a scheduled task.

[0041] Broadcast timing refers to a logical sequence composed of broadcast instance identifiers arranged sequentially in a message queue, reflecting a chronological order. It is not a pre-calculated static schedule, but a dynamic execution chain built in real-time by a series of timer-triggered events. This broadcast timing accurately reflects the trigger points of each broadcast instance on its independent timeline, serving as the basis for scheduling decisions by the scheduling task.

[0042] In one alternative approach, when a periodic timer expires and triggers an interrupt, the system runs within the timer callback function's context. Because the timer context has strict execution time constraints and cannot call functions that might cause blocking, the system does not directly manipulate the complex Bluetooth protocol stack here. Instead, the system constructs only a message structure containing the identifier of the current broadcast instance. Subsequently, the system calls the message queue's send function to attempt to send the broadcast instance identifier to the tail of the message queue. If the message queue is not full, the broadcast instance identifier is immediately stored; if the message queue is full, the system can choose to discard the broadcast event or overwrite older broadcast events based on priority. After the enqueue operation is complete, the timer callback function exits immediately.

[0043] In another alternative approach, for scenarios with extremely high real-time requirements, the system defines different message priorities for the message queue. When the periodic timer detects that the broadcast interval has been reached, the system not only sends a broadcast instance identifier but also appends the current timestamp to the message. If the system detects a triggering event for a first-type broadcast instance, it may call the high-priority sending interface of the message queue to ensure that broadcast requests for first-type broadcast instances are processed before those for second-type broadcast instances. This priority-based queuing mechanism ensures that, in the event of message congestion, critical first-type broadcast requests are not blocked by lower-priority first-type broadcast requests.

[0044] Step S30: Based on the broadcast timing, broadcast data corresponding to the broadcast instance identifiers are scheduled to be broadcast sequentially.

[0045] Broadcast data refers to the binary bit stream ultimately transmitted via BLE radio frequency. For the first type of broadcast instance, this broadcast data follows the Matter standard protocol format and includes a specific service-specific universally unique identifier, device information fields, etc. For the second type of broadcast instance, this data follows a user-defined protocol's proprietary format and may include device serial number, hardware version, operating status, or encrypted debugging instructions, etc.

[0046] In one alternative approach, after the scheduling task reads a broadcast instance identifier from the head of the message queue, it first acquires a global broadcast mutex to ensure that no other task or interrupt attempts to modify the broadcast parameters during the operation. Next, the scheduling task determines whether the broadcast instance identifier corresponds to the currently broadcasting instance. If not, the scheduling task first calls the underlying Bluetooth protocol stack interface to stop the current broadcast operation. Subsequently, depending on the type of the broadcast instance identifier, if it is a first-type broadcast instance identifier, the local Bluetooth address type is dynamically switched to a random static address; if it is a second-type, it is switched to a public address. Immediately afterward, the scheduling task writes the broadcast data and scan response data of the corresponding instance into the protocol stack's dedicated buffer and sets a new broadcast time interval. After all parameters are configured, the mutex is released, and the protocol stack's start broadcast interface is called. The scheduling task then waits for a broadcast start semaphore from the protocol stack to confirm that the BLE radio frequency has switched to data transmission for the new broadcast instance before re-entering the blocking state to wait for the next broadcast instance identifier in the message queue. This process ensures that each broadcast switch is atomic, avoiding the possibility of parameter aliasing.

[0047] In another alternative approach, when the scheduling task processes a request for a first-type broadcast instance, it does not immediately prepare for the next switch after initiating the broadcast. Instead, it sets an internal flag indicating that it is currently in Matter continuous broadcast mode. During this period, although the message queue may still contain identifiers for second-type broadcast instances, the scheduling task will temporarily lower the scheduling priority of the second-type broadcast based on internal flags, such as the Matter network configuration incomplete flag, or insert a longer protection interval before initiating the second-type broadcast instance. When processing second-type broadcast instances, since they are typically used for discontinuous debugging or upgrades, the scheduling task can proactively reassess whether to switch back to broadcasting the broadcast data of the first-type broadcast instance after sending the broadcast data corresponding to one broadcast instance.

[0048] In this embodiment, by creating independent periodic timers for the first type of broadcast instance conforming to the Matter specification and the second type of broadcast instance conforming to the user-defined protocol, the triggering rhythm of each broadcast instance is precisely controlled by its corresponding timer, thereby constructing an asynchronous triggering mechanism for multiple broadcast instances at the software level. When the periodic timer expires, only the corresponding broadcast instance identifier is sent to the message queue to generate a broadcast sequence. Based on this broadcast sequence, the corresponding broadcast data is scheduled sequentially. The broadcast requirements of the first type of broadcast instance of the Matter protocol and the second type of broadcast instance of the user-defined protocol can be simultaneously met on a single BLE radio frequency in a time-division multiplexing manner. Thus, without expanding the hardware broadcast capabilities, the problem of a single radio frequency being unable to be compatible with multiple types of protocol broadcasts is solved, and the broadcasting of multiple types of protocols is realized through a single radio frequency.

[0049] In one feasible implementation, broadcast data is broadcast via BLE radio frequency (RF), with the RF broadcasting data corresponding to a single broadcast instance at any given time. Here, BLE radio frequency refers to the front-end hardware module in the Bluetooth Low Energy chip responsible for radio wave transmission and reception. It is the physical carrier of the entire broadcast process, responsible for modulating digital signals into radio waves for transmission. In low-cost chips, there is typically only one such RF module; therefore, it can only perform one transmit or receive task at any given time and cannot handle multiple broadcast data streams simultaneously.

[0050] The step S30 above, which sequentially schedules the broadcast data corresponding to the broadcast instance identifier for broadcasting, includes: Step S31: Acquire the mutex lock of the current broadcast instance.

[0051] A mutex lock is a software mechanism used for synchronization between multiple threads or interrupts and tasks, similar to a key. When a scheduled task acquires the lock, other scheduled tasks attempting to acquire the same lock will be blocked and enter a waiting state until the lock is released. In this scheme, it is used to protect the integrity of broadcast parameter configurations, preventing interruptions during updates to addresses, data, or intervals, which could lead to configuration corruption.

[0052] In one alternative approach, when a scheduled task reads a broadcast instance identifier from the message queue and prepares to perform a broadcast switching operation, it first calls the system-provided mutex acquisition function to acquire a global mutex named "Broadcast Parameter Lock." At this point, the system checks if the mutex is already held by another task. If no other task is currently operating on the broadcast parameters, the scheduled task will successfully acquire the mutex. If, at this time, another low-priority task is modifying the broadcast parameters, or a callback function attempts to access related resources, the scheduled task will be suspended and enter a blocked state until the mutex is released. This mechanism ensures that even the highest-priority interrupt cannot be forcibly inserted during parameter updates, thus guaranteeing the atomicity of the configuration process.

[0053] Step S32: Adjust the address type of the local device in the underlying Bluetooth protocol stack to match the address type of the current broadcast instance, and configure the broadcast parameters corresponding to the BLE radio frequency according to the broadcast parameters corresponding to the current broadcast instance.

[0054] The underlying Bluetooth protocol stack refers to the lower-level part of the Bluetooth software protocol stack running on smart home devices, typically including the link layer and host control interface. It interacts directly with the hardware driver and is responsible for handling complex Bluetooth specification logic. The application layer controls broadcasting, stopping, and parameter settings by calling its provided application programming interfaces.

[0055] The local device address type refers to the category of physical address used by smart home devices when broadcasting. The Bluetooth specification defines several address types, among which public addresses are fixed, globally unique addresses registered with IEEE; random static addresses are addresses randomly generated when the device starts up and remain unchanged until power is lost. The choice of address type directly affects the device's privacy protection and identification methods.

[0056] Broadcast parameters contain a set of all the configuration information required to perform a broadcast. In addition to the address type, it also includes the broadcast data itself, scan response data, broadcast interval, broadcast channel mapping, broadcast type, etc. These parameters together determine the content and transmission method of the broadcast packet.

[0057] In one optional approach, after successfully acquiring the mutex lock, the scheduling task first queries the pre-stored broadcast parameters of the broadcast instance based on the broadcast instance identifier. Next, the scheduling task calls the address type setting interface provided by the underlying Bluetooth protocol stack, passing in the queried address type. The underlying Bluetooth protocol stack modifies the relevant registers of the BLE radio frequency, switching the Bluetooth address of the local smart home device to the corresponding address type. Then, the scheduling task continues to call the underlying Bluetooth protocol stack interface to set the broadcast parameters sequentially: writing the Matter broadcast data carried by the current broadcast instance or the vendor's proprietary broadcast data into the broadcast data buffer of the underlying Bluetooth protocol stack; setting scan response data for returning response information when the device is actively scanned; and setting the broadcast interval, writing the broadcast instance-specific time interval configuration into the timer.

[0058] Optionally, the address type includes public addresses and random static addresses. Adjusting the address type of the local device in the underlying Bluetooth protocol stack to match the current broadcast instance includes: when the current broadcast instance is a first-type broadcast instance, configuring the address type of the local device in the underlying Bluetooth protocol stack to a random static address to comply with the Matter protocol specification's requirements for device privacy protection; when the current broadcast instance is a second-type broadcast instance, configuring the address type of the local device in the underlying Bluetooth protocol stack to a public address to maintain compatibility with the manufacturer's existing applications and cloud platforms.

[0059] Step S33: Release the mutex lock.

[0060] In one alternative approach, after confirming that all broadcast parameters have been successfully written to the underlying Bluetooth protocol stack and that the underlying Bluetooth protocol stack has returned a confirmation message indicating successful configuration, the scheduling task calls the mutex release function provided by the system to release the previously acquired mutex lock. This operation will wake up all other tasks that were blocked while waiting for the lock. At this point, the system resources become shareable again, and other tasks that need to access broadcast parameters or radio frequency resources will have the opportunity to acquire the lock and perform operations.

[0061] Step S34: Trigger the underlying Bluetooth protocol stack to send a broadcast start command so that the BLE radio frequency broadcasts the broadcast data corresponding to the current broadcast instance with the updated broadcast parameters.

[0062] The broadcast start command is a command sent by the upper-layer application through a call to the underlying Bluetooth protocol stack interface. This command informs the underlying Bluetooth protocol stack that the currently configured broadcast parameters are ready and that actual radio transmission on the BLE radio frequency can begin according to the settings.

[0063] In one alternative approach, after releasing the mutex, the scheduling task invokes the start broadcast interface provided by the underlying Bluetooth protocol stack to send a command to start broadcasting. Upon receiving this command, the underlying Bluetooth protocol stack performs a series of internal checks to confirm that the broadcast parameters are ready and that the BLE radio frequency is idle or preemptible. Subsequently, the link layer controller of the underlying Bluetooth protocol stack takes over the BLE radio frequency and automatically controls it to periodically send broadcast packets on different broadcast channels according to the previously configured broadcast parameters. At this point, external Bluetooth terminal devices can scan for broadcast signals emitted by this device that match the characteristics of the current broadcast instance.

[0064] Step S35: When a broadcast completion signal is received for the broadcast data corresponding to the current broadcast instance, switch to the broadcast operation of the next broadcast instance.

[0065] The broadcast completion signal is typically obtained by the underlying Bluetooth protocol stack after a specific broadcast event occurs. In this scheme, it does not mean that a single broadcast packet has been sent, but rather that the underlying Bluetooth protocol stack has successfully received and processed the start broadcast command, confirmed that the broadcast parameters have taken effect, and that the BLE radio frequency has entered the expected broadcast state. The scheduling task waits for this broadcast completion signal to ensure the stable operation of the current broadcast instance before releasing resources or preparing for the next handover.

[0066] In one alternative approach, after sending the start broadcast command, the scheduling task does not immediately return to process the next event in the message queue. Instead, it calls the system-provided semaphore wait function to wait for a broadcast completion semaphore. Once the underlying Bluetooth protocol stack successfully starts the broadcast and confirms that the BLE radio frequency has begun transmitting stably according to the broadcast parameters, it calls the semaphore publish function to release the semaphore. Once the scheduling task acquires this semaphore, it confirms that the current broadcast instance has successfully come online and is running stably. At this point, the scheduling task ends its current processing flow, returns to the main loop, and blocks again to wait for the next broadcast instance identifier in the message queue, thus naturally switching to the process of handling the next broadcast instance.

[0067] In this embodiment, the mutex lock of the current broadcast instance is acquired; the address type of the local device in the underlying Bluetooth protocol stack is adjusted to match the address type of the current broadcast instance, and the broadcast parameters corresponding to the BLE radio frequency are configured according to the broadcast parameters corresponding to the current broadcast instance; the mutex lock is then released. By introducing the mutex lock, configuration conflicts, data overwriting, or hardware anomalies caused by multiple execution flows simultaneously competing to modify broadcast parameters in a multi-tasking environment are effectively avoided, providing a safe and reliable prerequisite for subsequent accurate parameter switching. After releasing the mutex lock, the underlying Bluetooth protocol stack is triggered to send a broadcast start command, so that the BLE radio frequency broadcasts the broadcast data corresponding to the current broadcast instance with the updated broadcast parameters. When the broadcast completion signal of the broadcast data corresponding to the current broadcast instance is received, the broadcast operation of the next broadcast instance is switched. This synchronous waiting mechanism ensures the orderliness and stability of broadcast switching. It prevents the scheduling task from hastily switching to the next one before the broadcast has actually started, avoiding broadcast instability or failure caused by too fast switching, improving the reliability of time-division multiplexing scheduling, and ensuring that each broadcast instance can obtain sufficient broadcast time.

[0068] In an optional manner, step S10, which creates an independent periodic timer for each type of broadcast instance based on the broadcast time interval corresponding to each type of broadcast instance, may further include: creating an independent first periodic timer for the first type of broadcast instance based on the first broadcast time interval corresponding to the first type of broadcast instance; and creating an independent second periodic timer for the second type of broadcast instance based on the second broadcast time interval corresponding to the second type of broadcast instance. Step S20, which detects the broadcast time interval of the corresponding broadcast instance through the periodic timer and sends the corresponding broadcast instance identifier to the message queue to obtain the broadcast timing sequence, may further include: sending the broadcast instance identifier corresponding to the first type of broadcast instance to the message queue when the first periodic timer reaches the first broadcast time interval; sending the broadcast instance identifier corresponding to the second type of broadcast instance to the message queue when the second periodic timer reaches the second broadcast time interval; generating the broadcast timing sequence based on the broadcast instance identifiers corresponding to the first type of broadcast instance, the broadcast instance identifiers corresponding to the second type of broadcast instance, and the time when each broadcast instance is sent to the message queue; wherein the first broadcast time interval is shorter than the second broadcast time interval. By setting corresponding periodic timers for the first type of broadcast instance and the second type of broadcast instance based on their different broadcast time intervals, the first type of broadcast instance and the second type of broadcast instance can be sent to the message queue in an orderly manner based on their set broadcast time intervals and the characteristic that the first broadcast time interval is shorter than the second broadcast time interval. This results in a broadcast sequence including the broadcast instance identifiers corresponding to different types of broadcast instances, thus realizing the construction of broadcast sequence.

[0069] In one feasible implementation, the method further includes: Upon receiving a start request for the target broadcast instance, the start / stop flag of the target broadcast instance is set to running status, a periodic timer corresponding to the target broadcast instance is created, and the first broadcast data of the target broadcast instance is sent to the message queue to trigger the first broadcast.

[0070] A target broadcast instance refers to a specific broadcast instance that is selected or specified in the current operation context. It can be either a Type I or Type II broadcast instance. The system distinguishes different target broadcast instances by a unique broadcast instance identifier in order to perform independent start, stop, or parameter configuration operations on them.

[0071] A startup request is a control command initiated by the application layer or other system modules to activate a broadcast instance that is idle or inactive. For example, when a user opens a mobile app to configure a smart lighting device, the app sends a startup request for the Matter broadcast instance to the smart lighting device. This request typically includes the broadcast instance's identifier and initial configuration parameters. The start / stop flag is a Boolean variable or enumerated state variable stored in the broadcast instance's structure, used to reflect the current working status of the broadcast instance in real time. Common states include running, stopped, and suspended. When processing message queues or timer events, the scheduling task first checks this start / stop flag to determine whether to execute the actual broadcast operation. The running state is one value of the start / stop flag, indicating that the broadcast instance has been activated, allowing its periodic timer to trigger broadcast events and allowing the scheduling task to process its broadcast requests. Instances in this state will continuously participate in broadcast scheduling according to a preset broadcast time interval.

[0072] In one alternative approach, when the system receives a startup request from the application layer, it first locates the data structure of the target broadcast instance in memory based on the target broadcast instance identifier carried in the request. Next, the system modifies the start / stop flag field within this data structure from a stopped state to a running state. Subsequently, the system calls the timer creation interface to generate a new periodic timer for the instance. During creation, the system reads the instance's preset broadcast interval from its configuration information, converts this interval into the timing parameters required by the timer, and binds the timer's callback function to the broadcast instance's processing logic. After successful timer creation, the system does not start it directly but instead constructs an initial broadcast message containing the target broadcast instance identifier. This initial broadcast message is not triggered by the timer but is actively generated by the startup logic. Finally, the system calls the message queue sending interface to post this initial broadcast message to the tail of the scheduling task's message queue. Once the scheduling task is awakened, it processes this message like a normal timer event, immediately executing a broadcast parameter configuration and sending process.

[0073] Alternatively, upon receiving a stop request from the target broadcast instance, set the start / stop flag of the target broadcast instance to the stop state, delete the periodic timer corresponding to the target broadcast instance, and release the broadcast parameter buffer and mutex lock occupied by the target broadcast instance.

[0074] A stop request is a control command initiated by the application layer or other system modules to terminate a running broadcast instance. For example, after Matter network configuration is successful, the system can send a stop request to shut down Matter broadcasting, thereby saving power. This stop request causes the corresponding periodic timer to be deleted, and broadcasting behavior stops immediately. The stop state is a value of the start / stop flag, indicating that the broadcast instance has been disabled. Instances in this state will not generate interrupts through their periodic timers, and scheduling tasks will ignore any broadcast requests associated with them. Even if the underlying hardware is still running other broadcast instances, this broadcast instance will not consume radio frequency resources.

[0075] The broadcast parameter buffer is a specially allocated memory area used to store broadcast data, scan response data, and other related configuration parameters for a specific broadcast instance. Each active broadcast instance has its own independent buffer to prevent data interference. When a broadcast instance stops, this broadcast parameter buffer can be released to reclaim memory.

[0076] In one alternative approach, when the system receives a stop request for a target broadcast instance, it first locates the corresponding data structure based on the target broadcast instance identifier. The system then changes its start / stop flag from running to stopped. This change takes effect immediately, even if the target broadcast instance's periodic timer has not yet expired; its next expiration event will be ignored by the scheduled task. Next, the system calls the real-time operating system's timer deletion interface, passing in the timer identifier corresponding to the target broadcast instance, to completely destroy the timer, preventing it from generating any callbacks. Subsequently, the system checks the broadcast parameter buffer of the target broadcast instance. If the broadcast parameter buffer is dynamically allocated, the system calls the memory release function to return it to the system heap; if it is statically allocated, the system marks it as unused. Finally, the system calls the mutex lock deletion interface to destroy the mutex lock associated with the broadcast parameter buffer, or invalidates it. The entire process ensures that all dynamic resources related to the target broadcast instance are completely reclaimed.

[0077] Alternatively, upon receiving a system deinitialization request, set the system deinitialization flag, send a deinitialization broadcast instance identifier to the message queue, and exit the scheduled task.

[0078] A system deinitialization request is a system-level control command typically issued by the system manager when a device is about to shut down, restart, or enter deep sleep mode. This request requires the system to cease all activity, release all occupied resources, and gracefully exit scheduled tasks to ensure system consistency and predictability. The system deinitialization flag is a global state variable used to signal to scheduled tasks that the system is shutting down; once this flag is set, all new broadcast requests will be rejected, and ongoing broadcast operations will be terminated as soon as possible so that the system can smoothly enter the low-power or shutdown process.

[0079] The scheduling task is a long-running background task and the core execution engine of the broadcast method in this scheme. It typically contains a main loop that blocks and waits for messages in the message queue. Once a message is received, whether it is a broadcast instance identifier or a system deinitialization identifier, it will call the corresponding processing logic to perform broadcast switching, parameter configuration, or resource cleanup.

[0080] In one alternative approach, when the system manager detects that a device is about to power down, restart, or enter deep sleep, it issues a system deinitialization request. Upon receiving this request, the system handler first accesses and modifies a global system deinitialization flag variable, setting its value to true. This flag is a globally visible signal that the main loop of the scheduling task checks periodically. Next, the system constructs a deinitialization broadcast instance identifier. The value of this identifier is defined as a constant that cannot conflict with a regular broadcast instance identifier. The system calls the message queue's send interface to deliver this deinitialization identifier to the scheduling task's message queue with high priority or front-end insertion. When the scheduling task is awakened and reads this identifier, it realizes that the system is shutting down. At this point, the scheduling task skips all regular broadcast processing logic and instead executes a cleanup procedure: it iterates through all known broadcast instances, forcibly placing them in a stopped state and calling their respective resource release functions to release the corresponding resources.

[0081] In this embodiment, setting the running state provides admission control for subsequent timers and scheduling logic; setting the stop state enables immediate soft shutdown of broadcast behavior; deleting periodic timers eliminates unnecessary system interruptions and timing overhead; and releasing the broadcast parameter buffer and mutex effectively prevents memory leaks and resource exhaustion, ensuring system stability during long-term operation. By setting a system deinitialization flag, the existing message queue mechanism gracefully notifies and drives the scheduled task to perform self-cleanup, avoiding data inconsistencies or resource leaks that might result from forced task termination. This ensures that the entire broadcast system can reliably complete the final stage of its lifecycle as an organic whole, improving system robustness and maintainability.

[0082] In one feasible implementation, during the broadcasting of broadcast data via BLE radio frequency, the method further includes: real-time monitoring of the Bluetooth connection status of the BLE radio frequency; when the Bluetooth terminal device connection is established based on the Bluetooth connection status, pausing the periodic timers of all broadcast instances and stopping the sending of new broadcast instance identifiers to the message queue; when the Bluetooth terminal device disconnects based on the Bluetooth connection status, resuming the periodic timers of each broadcast instance, resending the corresponding broadcast instance identifiers to the message queue, and performing subsequent scheduling and broadcasting operations. By monitoring the connection status of the BLE radio frequency in real time, the system immediately pauses the periodic timers of all broadcast instances when a Bluetooth terminal device establishes a connection, thereby blocking the injection of new broadcast instance identifiers into the message queue. This effectively avoids the contention between broadcast and connected states for a single BLE radio frequency resource, preventing broadcast anomalies or connection interruptions caused by protocol stack state chaos. When the connection is lost, the system automatically resumes the operation of each periodic timer and re-injects the broadcast instance identifier into the message queue, enabling each broadcast instance to quickly return to the predetermined time-division multiplexing scheduling sequence. This ensures seamless connection and dynamic balance between Matter broadcasts and private broadcasts throughout the entire lifecycle of the connection event, guaranteeing both the stability of Bluetooth connection services and maintaining high discoverability of devices in the non-connected state.

[0083] In one feasible implementation, before step S10, the broadcast time interval of the first type of broadcast instance includes a fast broadcast interval and a slow broadcast interval; the method further includes: monitoring the current distribution network status of the first type of broadcast instance; when the distribution network status is in the distribution network discovery stage, configuring the broadcast time interval of the first type of broadcast instance as a fast broadcast interval, the value range of the fast broadcast interval being 20 milliseconds to 60 milliseconds; when the distribution network status is in the distribution network completion stage or idle state, switching the broadcast time interval of the first type of broadcast instance to a slow broadcast interval, the value range of the slow broadcast interval being 150 milliseconds to 1200 milliseconds. By setting different broadcast intervals for the first type of broadcast instances based on different network configuration states, a fast broadcast interval of 20 to 60 milliseconds is used during the network configuration discovery phase, which shortens the scanning window matching time of Bluetooth terminal devices, improves the response speed of Matter device discovery and network configuration success rate, and effectively optimizes the user's initial network configuration experience. When network configuration is completed or the device is in an idle state, the broadcast interval is automatically switched to a slow broadcast interval of 150 to 1200 milliseconds. While meeting the maintainability requirements of still being discoverable by the device, the duty cycle of the BLE radio frequency and system power consumption are reduced, achieving a balance between network configuration efficiency and energy consumption control.

[0084] For example, to help understand the implementation flow of the broadcast method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 2 , Figure 2A system architecture diagram of a broadcast method is provided. Specifically, the system architecture of this application includes an application layer, a broadcast scheduling layer, a BLE protocol stack layer, and a radio frequency hardware layer. The application layer includes a MatterBLE manager and a user BLE manager. The MatterBLE manager is used to send Matter broadcast parameters to the broadcast scheduling layer, which sends them to a message queue via timer B (first-cycle timer); then, through a scheduling task, it retrieves the broadcast data corresponding to the first type of broadcast instance from the message queue, performs broadcast control through the BLE protocol stack layer, and broadcasts via a single BLE radio frequency of the radio frequency hardware layer. The user BLE manager is used to send user broadcast parameters to the broadcast scheduling layer, which sends them to a message queue via timer A (second-cycle timer); then, through a scheduling task, it retrieves the broadcast data corresponding to the second type of broadcast instance from the message queue, performs broadcast control through the BLE protocol stack layer, and broadcasts via a single BLE radio frequency of the radio frequency hardware layer.

[0085] For example, consider smart lighting devices as a smart home device. It needs to simultaneously meet the following requirements: support for the Matter standard protocol and support for user-defined protocols. In practical applications, after the smart lighting device is powered on, it initializes a first type of broadcast instance and a second type of broadcast instance. The first type of broadcast instance uses a random static address with a broadcast interval configured to 100ms; the second type of broadcast instance uses a public address with a broadcast interval configured to 200ms. A periodic timer T1 with a timer of 100ms is created for the first type of broadcast instance, and a periodic timer T2 with a timer of 200ms is created for the second type of broadcast instance. After T1 expires, the broadcast instance identifier corresponding to the first type of broadcast instance is sent to the message queue; after T2 expires, the broadcast instance identifier corresponding to the second type of broadcast instance is sent to the message queue. If the scheduling task reads the first type of broadcast instance from the message queue, it switches the BLE address type to a random static address and starts broadcasting the broadcast data corresponding to the first type of broadcast instance, continuing until the next timer event. If the scheduling task reads the second type of broadcast instance from the message queue, it switches to a public address and starts broadcasting the broadcast data corresponding to the second type of broadcast instance. At this point, the Bluetooth terminal device scans and detects the broadcast data corresponding to the first type of broadcast instance, thus completing network pairing with the smart lighting device. Simultaneously, the manufacturer's debugging personnel use the manufacturer's app to scan for the broadcast data corresponding to the second type of broadcast instance, entering engineering mode for parameter calibration. These two processes do not interfere with each other; there is no need to disable private broadcasting after network pairing or restart the device to switch modes. This allows a single BLE radio frequency to simultaneously support broadcasting of two protocols.

[0086] Please refer to Figure 3 , Figure 3This is a schematic diagram of the broadcast timing in this application. There are 3 first-type broadcast instances and 2 second-type broadcast instances. The final broadcast timing of each broadcast instance is as follows: Figure 3 As shown.

[0087] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the broadcasting method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0088] Based on the same inventive concept, this application provides a broadcasting device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the broadcasting method in the above embodiments. This broadcasting device can be any smart home device with BLE radio frequency capability.

[0089] The broadcasting device provided in this application, employing the broadcasting method in the above embodiments, can solve the technical problem that a single BLE radio frequency cannot simultaneously meet the broadcasting needs of multiple broadcast instances of different protocol types. Compared with the prior art, the beneficial effects of the broadcasting device provided in this application are the same as those of the broadcasting method provided in the above embodiments, and other technical features in this broadcasting device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0090] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0092] Based on the same inventive concept, this application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the broadcasting method in the above embodiments.

[0093] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0094] The aforementioned computer-readable storage medium may be included in a broadcasting device or may exist independently without being assembled into a broadcasting device.

[0095] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a broadcasting device, cause the broadcasting device to perform the steps of the aforementioned broadcasting method.

[0096] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0097] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0098] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0099] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described broadcasting method. This solves the technical problem that a single BLE radio frequency cannot simultaneously meet the broadcasting requirements of multiple broadcast instances of different protocol types. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the broadcasting method provided in the above embodiments, and will not be repeated here.

[0100] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A broadcasting method, characterized in that, The method includes: Based on the broadcast time interval corresponding to each type of broadcast instance, an independent periodic timer is created for each type of broadcast instance. The broadcast instances include a first type of broadcast instance that conforms to the Matter standard protocol specification and a second type of broadcast instance that conforms to a user-defined protocol. When the broadcast time interval corresponding to the broadcast instance is detected by the periodic timer, the corresponding broadcast instance identifier is sent to the message queue to obtain the broadcast timing. Based on the broadcast timing, broadcast data corresponding to the broadcast instance identifiers are scheduled to be broadcast sequentially.

2. The broadcasting method as described in claim 1, characterized in that, The broadcast data is broadcast via BLE radio frequency, and at any given time, the BLE radio frequency broadcasts broadcast data corresponding to a broadcast instance; the step of sequentially scheduling the broadcast data corresponding to the broadcast instance identifier for broadcasting includes: Acquire the mutex lock for the current broadcast instance; Adjust the address type of the local device in the underlying Bluetooth protocol stack to match the address type of the current broadcast instance, and configure the broadcast parameters corresponding to the BLE radio frequency according to the broadcast parameters corresponding to the current broadcast instance; Release the mutex lock; Trigger the underlying Bluetooth protocol stack to send a broadcast start command, so that the BLE radio frequency broadcasts the broadcast data corresponding to the current broadcast instance with updated broadcast parameters; Upon receiving a broadcast completion signal for the broadcast data corresponding to the current broadcast instance, the broadcast operation is switched to the next broadcast instance.

3. The broadcasting method as described in claim 2, characterized in that, The address types include public addresses and random static addresses; adjusting the address type of the local device in the underlying Bluetooth protocol stack to match the address type of the current broadcast instance includes: When the current broadcast instance is a first type broadcast instance, the address type of the local device of the underlying Bluetooth protocol stack is configured to the random static address; When the current broadcast instance is a second type broadcast instance, the address type of the local device of the underlying Bluetooth protocol stack is configured to the public address.

4. The broadcasting method as described in claim 1, characterized in that, The step of creating an independent periodic timer for each type of broadcast instance based on the broadcast time interval corresponding to each type of broadcast instance includes: Based on the first broadcast time interval corresponding to the first type of broadcast instance, an independent first period timer is created for the first type of broadcast instance; and Based on the second broadcast time interval corresponding to the second type of broadcast instance, create an independent second period timer for the second type of broadcast instance; When the broadcast time interval corresponding to the broadcast instance is detected by the periodic timer, the corresponding broadcast instance identifier is sent to the message queue to obtain the broadcast timing, which includes: When the first periodic timer reaches the first broadcast time interval, the broadcast instance identifier corresponding to the first type of broadcast instance is sent to the message queue; When the second periodic timer reaches the second broadcast time interval, the broadcast instance identifier corresponding to the second type of broadcast instance is sent to the message queue; and The broadcast sequence is generated based on the broadcast instance identifier corresponding to the first type of broadcast instance, the broadcast instance identifier corresponding to the second type of broadcast instance, and the time when each broadcast instance is sent to the message queue. Wherein, the first broadcast time interval is shorter than the second broadcast time interval.

5. The broadcasting method as described in claim 1, characterized in that, The method further includes: Upon receiving a start request for a target broadcast instance, the start / stop flag of the target broadcast instance is set to running, a periodic timer corresponding to the target broadcast instance is created, and the first broadcast data of the target broadcast instance is sent to the message queue to trigger the first broadcast; or, Upon receiving a stop request from the target broadcast instance, set the start / stop flag of the target broadcast instance to the stop state, delete the periodic timer corresponding to the target broadcast instance, and release the broadcast parameter buffer and mutex lock occupied by the target broadcast instance; or, Upon receiving a system deinitialization request, a system deinitialization flag is set, and the system deinitialization flag is sent to the message queue to exit the scheduling task.

6. The broadcasting method according to any one of claims 1 to 5, characterized in that, The first type of broadcast instance is used to send first broadcast data that conforms to the Matter protocol specification. The first broadcast data includes at least a vendor identification code, a product identification code, device type information, and network configuration identification information, so that the Matter controller can complete device discovery and network configuration based on the first broadcast data. The second type of broadcast instance is used to send second broadcast data that conforms to a user-defined protocol. The second broadcast data includes at least a vendor-specific protocol identifier, a device serial number, and debugging information, so that the vendor-specific application can perform device identification, parameter configuration, or firmware upgrade.

7. The broadcasting method as described in claim 1, characterized in that, The method further includes: During the broadcast of the broadcast data via BLE radio frequency, the Bluetooth connection status of the BLE radio frequency is monitored; When a Bluetooth terminal device connection is established based on the Bluetooth connection status, the periodic timers for all broadcast instances are paused, and the sending of new broadcast instance identifiers to the message queue is stopped. When the Bluetooth terminal device is disconnected based on the Bluetooth connection status, the periodic timer of each broadcast instance is restored, the corresponding broadcast instance identifier is resent to the message queue, and subsequent scheduling and broadcast operations are performed.

8. The broadcasting method as described in claim 1, characterized in that, The broadcast time interval for the first type of broadcast instance includes a fast broadcast interval and a slow broadcast interval; the method further includes: Monitor the current network configuration status of the first type of broadcast instance; When the distribution network is in the distribution network discovery phase, the broadcast time interval of the first type of broadcast instance is configured as the fast broadcast interval, and the value of the fast broadcast interval is in the range of 20 milliseconds to 60 milliseconds; When the distribution network is in the distribution network completion stage or idle state, the broadcast time interval of the first type of broadcast instance is switched to the slow broadcast interval, the value range of which is 150 milliseconds to 1200 milliseconds.

9. A broadcasting device, characterized in that, The apparatus includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the broadcasting method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the broadcasting method as described in any one of claims 1 to 8.

Images