Multi-source heterogeneous BLE device data aggregation processing method and related device

Abstract

The embodiment of the present application relates to the technical field of Internet of Things, and discloses a multi-source heterogeneous BLE device data aggregation processing method and related equipment, the method comprises the following steps: obtaining label data of a BLE device, the label data comprising a device type and a connection address; establishing a connection with the BLE device according to the connection address, and receiving original data sent by the BLE device; matching a corresponding data parser according to the device type of the BLE device, analyzing the original data according to the data parser, and obtaining target data; based on a predetermined data frame format, aggregating the current timestamp, the device type of the BLE device and the target data into a unified standard data frame; and distributing the standard data frame to a corresponding channel according to the device type, so as to send the standard data frame to a corresponding target platform. In the above manner, the embodiment of the present application has strong multi-source heterogeneous data processing capability, does not need an upper application to write code to distinguish data sources and analyze protocols, and reduces code redundancy.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, specifically to a method for data aggregation and processing of multi-source heterogeneous BLE devices and related equipment. Background Technology

[0002] Bluetooth Low Energy (BLE) devices are wireless communication hardware designed for power conservation, operating only briefly when needed, making them suitable for Internet of Things (IoT) devices. With the rapid development of IoT technology, distributed sensing networks composed of multiple BLE sensor nodes have become a crucial infrastructure for environmental sensing, vital sign monitoring, and device status monitoring. In practical applications, to comprehensively acquire information about target objects, it is often necessary to deploy multiple different types of sensors working collaboratively. For example, simultaneously deploying vital sign sensors for monitoring heart rate and body temperature, posture sensors for capturing motion, and positioning sensors for obtaining location information.

[0003] To achieve centralized management of these dispersed nodes, the industry typically uses BLE gateways as data aggregation hubs. Traditional BLE gateways usually establish connections with peripheral devices by scanning for Bluetooth broadcast signals in the environment and receiving data reported by the devices. Furthermore, for data processing from multiple device types, existing gateway software is usually developed based on a fixed parsing protocol, or separate adaptation code is written in the upper-layer application for different types of devices to achieve the parsing and storage of heterogeneous data. Although existing technologies have solved the problems of device connectivity and data transmission to some extent, they still have the following significant drawbacks when facing increasingly complex multi-source heterogeneous application scenarios: Traditional gateways usually treat the received BLE data as a homogeneous byte stream and forward it transparently. Because the data formats (such as byte order, field definitions, and physical quantity units) of different manufacturers and different types of sensors vary, upper-layer applications must write a large amount of redundant code to distinguish data sources and perform protocol parsing. This results in weak heterogeneous data processing capabilities, and once a sensor type is added or changed, the upper-layer application code needs to be modified, leading to redundant code and complex operations. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention provide a method and related equipment for data aggregation and processing of multi-source heterogeneous BLE devices to solve the problems existing in the prior art.

[0005] According to one aspect of the present invention, a gateway device is provided, the gateway device comprising: The acquisition module is used to acquire tag data of BLE devices. The tag data includes at least the device type and connection address. The BLE devices include one or more, and the multiple BLE devices include various different device types. The BLE central module is used to establish a connection with the BLE device based on the connection address and to receive raw data sent by the BLE device. The main control module includes a matching and parsing unit, a heterogeneous data aggregation unit, and a distribution unit. The matching and parsing unit is used to match the corresponding data parser according to the device type of the BLE device, and parse the original data according to the data parser to obtain the target data. The heterogeneous data aggregation unit is used to aggregate the current timestamp, the device type of the BLE device, and the target data into a unified standard data frame based on a predetermined data frame format. The distribution unit is used to distribute the standard data frame to the corresponding channel according to the device type, so as to send the standard data frame to the corresponding target platform.

[0006] In one alternative approach, the data parser is a structure that includes a parsing template, physical quantity units, and scaling factors; The matching parsing unit is specifically used to take the original data as input parameters, call the member function of the data parser, and the member function extracts the physical quantity from the original data according to the parsing template in the structure, and generates the target data based on the physical quantity, the unit of the physical quantity and the scaling factor.

[0007] In an optional approach, a list module is also included, which is used to generate a device list based on the device type and the connection address, and store it in a preset database; The BLE central module is specifically used to establish connections with the corresponding BLE devices sequentially according to the connection addresses in the device list, using a delayed queue scheduling algorithm and a preset delay time slot.

[0008] In one alternative approach, the acquisition module is an NFC card reader, the tag data is NFC tag data, and each BLE device is configured with corresponding NFC tag data; The NFC reader is used to read the NFC tag data after being touched by the BLE device, and to parse the NFC tag data to obtain the device type and the connection address.

[0009] In one alternative approach, the NFC tag data further includes scene parameters, which are used to adaptively process the business scenario corresponding to the target data. The scene parameters include at least reporting frequency, anomaly detection threshold, and local early warning rules. The distribution unit is specifically used to distribute the standard data frame to the corresponding channel according to the device type and the reporting frequency, so as to send the standard data frame to the corresponding target platform; The main control module also includes an anomaly warning unit, which is used to perform anomaly detection on the target data according to the anomaly detection threshold; if an anomaly is detected in the target data, an early warning is issued according to the local early warning rules.

[0010] In one alternative approach, the NFC tag data also includes binding status parameters; The NFC reader is specifically used to read the NFC tag data after touching the BLE device, and to parse the NFC tag data to obtain the device type, the connection address, and the binding status parameters; if the binding status parameters are unbound, the BLE central module is triggered; otherwise, the BLE central module is not triggered.

[0011] According to another aspect of the present invention, a multi-source heterogeneous BLE device data aggregation and processing system is provided. The system includes a management terminal, BLE devices, and a gateway device as described above. The management terminal is used to configure the tag data of the BLE devices.

[0012] According to another aspect of the present invention, a method for data aggregation and processing of multi-source heterogeneous BLE devices applied to a gateway device as described above is provided, the method comprising: Acquire tag data of BLE devices, the tag data including device type and connection address, the BLE devices include one or more, and the multiple BLE devices include various different device types; Establish a connection with the BLE device based on the connection address, and receive raw data sent by the BLE device; Match the corresponding data parser according to the device type of the BLE device, and parse the original data according to the data parser to obtain the target data; Based on a predetermined data frame format, the current timestamp, the device type of the BLE device, and the target data are aggregated into a unified standard data frame; The standard data frame is distributed to the corresponding channel according to the device type, so as to send the standard data frame to the corresponding target platform.

[0013] According to another aspect of the present invention, a computer device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction causes the processor to perform the method described above.

[0014] According to another aspect of the present invention, a computer-readable storage medium is provided, the storage medium storing at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the method described above.

[0015] In this embodiment of the gateway device, the acquisition module acquires the tag data of the BLE device, the BLE center module establishes a connection with the BLE device based on the connection address, receives the raw data sent by the BLE device, the matching and parsing unit matches the corresponding data parser according to the device type of the BLE device, and parses the raw data according to the data parser to obtain the target data, the heterogeneous data aggregation unit aggregates the current timestamp, the device type of the BLE device, and the target data into a unified standard data frame based on a predetermined data frame format, and the distribution unit distributes the standard data frame to the corresponding channel according to the device type to send the standard data frame to the corresponding target platform. In this embodiment of the gateway device, the data carries the device type from the acquisition end, and the main control module automatically completes parsing, aggregation, and distribution according to the device type. It has strong multi-source heterogeneous data processing capabilities and does not require upper-layer applications to write code to distinguish data sources and parsing protocols, greatly reducing code redundancy.

[0016] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0017] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This diagram illustrates the usage environment of the gateway device provided in an embodiment of the present invention. Figure 2 This diagram illustrates the structure of a multi-source heterogeneous BLE device data aggregation and processing system according to an embodiment of the present invention. Figure 3 This diagram illustrates the structure of the multi-source heterogeneous BLE device data aggregation and processing method according to an embodiment of the present invention. Figure 4 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention is shown. Detailed Implementation

[0018] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0019] Figure 1 This diagram illustrates the usage environment of the gateway device provided in an embodiment of the present invention, such as... Figure 1 As shown, there are multiple BLE devices and corresponding platforms. The raw data sent by the BLE devices is transmitted to the corresponding platforms for processing after passing through the gateway device. Specifically, the gateway device first obtains the tag data of the BLE devices and establishes a connection with them based on the tag data. Then, the BLE devices transmit raw data to the gateway device. Since the data types, formats, and semantics of the raw data transmitted by different BLE device types vary, the gateway device needs to parse and standardize the data, and finally distribute it according to the channel of the device type. This ensures that the raw data from the BLE devices, after being uniformly processed by the gateway device, is sent to the corresponding target platform in a standardized form for processing. The gateway device includes an acquisition module, a BLE central module, and a main control module.

[0020] The acquisition module is used to acquire tag data of BLE devices. The tag data includes at least the device type and connection address. The BLE devices include one or more devices, and the multiple BLE devices include various different device types.

[0021] BLE devices can be one or more of the following: wearable health monitoring devices, smart home and office devices, and positioning and vehicle-mounted devices. Examples of wearable health monitoring devices include smart bracelets, smartwatches, fitness trackers, and Bluetooth blood pressure and blood glucose meters. Examples of smart home and office devices include temperature and humidity sensors, smoke detectors, smart light bulbs, curtain motors, smart door locks, Bluetooth keyboards, game controllers, and flight control gloves. Examples of positioning and vehicle-mounted devices include anti-loss trackers, car digital keys, tire pressure monitoring sensors, and positioning shoes. This embodiment does not limit the types of devices. Each BLE device obtains corresponding raw data through deployed sensors.

[0022] Tag data is a structured representation of the characteristics of a BLE device. In this embodiment, tag data includes device type and connection address. The device type uses a 1-byte enumeration value, such as 0x06 for vital sign devices, 0x07 for gesture devices, and 0x08 for location devices. The connection address is the MAC address of the BLE device.

[0023] In one embodiment, the gateway device and the terminal where the management terminal is located are connected via USB, WiFi, or LAN. The management terminal records the tag data of each BLE device and sends it to the gateway device. In another embodiment, the gateway device can obtain the tag data of each BLE device from the cloud. The method by which the gateway device obtains the tag data of the BLE devices is not limited in this embodiment.

[0024] The BLE central module is used to establish a connection with the BLE device based on the connection address and to receive raw data sent by the BLE device.

[0025] The BLE central module establishes connections with each BLE device individually using their connection addresses. If a connection is lost, it automatically reconnects. Once connected, the two devices can communicate via Bluetooth. Each BLE device sends raw data to the BLE central module, which receives this heterogeneous raw data from multiple sources. Since these BLE devices are of different types and from different manufacturers, they are heterogeneous devices, and therefore the format and semantics of the raw data received by the BLE central module may differ.

[0026] In existing technologies, BLE devices send raw data to gateway devices via MAC addresses. While the gateway device can determine the source of the raw data, it typically requires further code to determine the device type before parsing the raw data. Since there are many device types, the code for determining the device type leads to redundancy. This embodiment, through tag data, after obtaining the device type and connection address of the BLE device, can construct a device context mapping table (ContextMap) to establish the association between device type, connection address, and logical handle. ContextMap: MAC_Address↔DeviceType↔ConnectionHandle; The ConnectionHandle is a logical handle allocated by the protocol stack after the BLE central module establishes a physical connection with the BLE device. This mapping table enables a one-to-one correspondence between the underlying connection and the upper-layer semantics.

[0027] After the BLE device sends raw data, the BLE central module notifies the upper-layer application of the data arrival via a callback function, carrying the ConnectionHandle of the current connection. The BLE central module uses the ConnectionHandle as an index to query the device context map table ContextMap to determine the associated MAC_Address and DeviceType, thereby determining the device type corresponding to the raw data. This directly provides a clear indication for subsequent parsing logic, eliminating the need to write code to parse the device type and reducing code redundancy.

[0028] Furthermore, the gateway device also includes a list module, used to generate a device list based on the device type and the connection address, and store it in a preset database; The BLE central module is specifically used to establish connections with the corresponding BLE devices sequentially according to the connection addresses in the device list, using a delayed queue scheduling algorithm and a preset delay time slot.

[0029] In densely deployed scenarios requiring simultaneous connections to multiple BLE devices, traditional gateways typically employ polling or simple retry mechanisms to establish connections. When multiple BLE devices respond to connection requests simultaneously, radio frequency (RF) conflicts and connection timeouts are highly likely to occur, leading to missed connections or excessively long connection times, and lacking an effective connection scheduling mechanism. In this embodiment, the BLE central module, when establishing connections with BLE devices, uses a stored device list and a delayed queue scheduling algorithm to sequentially establish connections with the corresponding BLE devices according to a preset delay time slot (e.g., 5 seconds). This avoids RF conflicts and connection timeouts caused by multiple BLE devices simultaneously establishing connections, improving connection stability and orderliness.

[0030] The main control module includes a matching and parsing unit, a heterogeneous data aggregation unit, and a distribution unit. The matching and parsing unit is used to match the corresponding data parser according to the device type of the BLE device, and parse the original data according to the data parser to obtain the target data.

[0031] In this embodiment, a mapping table M, DeviceType-Parser, is defined between device types and data parsers. Mapping table M maintains the mapping relationship between device types and data parsers. The data parser includes the corresponding parsing rules for that device type, and the original data for that device type can be parsed using the parsing logic of these rules.

[0032] Furthermore, the data parser is a structure that includes a parsing template, physical quantity units, and scaling factors; The matching parsing unit is specifically used to take the original data as input parameters, call the member function of the data parser, and the member function extracts the physical quantity from the original data according to the parsing template in the structure, and generates the target data based on the physical quantity, the unit of the physical quantity and the scaling factor.

[0033] Wherein, the data parser Parser = {Template, Unit, Scale}; The template defines the byte offset, length, and byte order of the payload. The unit defines the measurement unit of the parsed data (such as bpm, ℃, V). The scaling factor is used to convert the original integer value into a floating-point coefficient of the actual physical quantity.

[0034] The raw data can be a byte stream. The payload is extracted from the raw data, and the `apply()` member function of the data parser is called, passing the payload as an input parameter. The execution logic of this function is as follows: ParsedData=Parser.apply(Payload), Specifically, the member function `apply()` breaks down the payload according to the parsing template defined within the structure. For example, for a vital signs device (0x06), its parsing template defines the first 1 bytes of the payload as the heart rate value, the second and third bytes as the body temperature value, and the fourth byte as the blood oxygen value. After reading the corresponding bytes, the member function multiplies them by the scaling factor `Scale` to generate a value with physical units, thus obtaining the target data and automatically extracting the correct physical quantity based on the device type.

[0035] For example, for BLE devices that detect vital signs, such as smart bracelets, the data parser obtains the following after parsing: [ {offset: 0, len: 2, unit: "bpm", scale: 1.0}, / / heart rate {offset: 2, len: 2, unit: "℃", scale: 0.01}, / / body temperature {offset: 4, len: 1, unit: "%", scale: 1.0}, / / blood oxygen ]; The final results showed a heart rate of 120 bpm, a body temperature of 36.52°C, and blood oxygen saturation of 100%.

[0036] The heterogeneous data aggregation unit is used to aggregate the current timestamp, the device type of the BLE device, and the target data into a unified standard data frame based on a predetermined data frame format. The standard data frame format is as follows: Frame=[Timestamp,DeviceType,ParsedData]; Timestamp is a high-precision timestamp at the millisecond level, used for time alignment of multi-source heterogeneous data. DeviceType is the device type, and ParsedData is the target data.

[0037] For each piece of target data, it is encapsulated into a standardized data frame according to the data frame format described above, resulting in a structured data frame. Of course, the standardized data frame can be modified based on the data frame format described above, such as by adding other information; this is not limited here.

[0038] The distribution unit is used to distribute the standard data frame to the corresponding channel according to the device type, so as to send the standard data frame to the corresponding target platform.

[0039] The distribution unit distributes standard data frames to the corresponding channels according to device type, enabling differentiated output of the standard data frames, and finally sends them to the corresponding target platforms for processing. For example, vital sign standard data frames are distributed to channel 1 and ultimately uploaded to the health analysis platform for health analysis, while location standard data frames are distributed to channel 2 and ultimately sent to the electronic fence service platform for location analysis, and so on.

[0040] Furthermore, the matching and parsing unit, heterogeneous data aggregation unit, and distribution unit in the main control module are implemented in software based on C++, which can run on the ARM Linux platform. The BLE central module is implemented using CC2340R53, achieving hardware and software decoupling: the core business logic such as parsing of raw data, heterogeneous data aggregation and distribution is implemented in software, which can be smoothly ported to different embedded platforms with low porting cost.

[0041] In this embodiment of the gateway device, the acquisition module acquires the tag data of the BLE device, the BLE center module establishes a connection with the BLE device based on the connection address, receives the raw data sent by the BLE device, the matching and parsing unit matches the corresponding data parser according to the device type of the BLE device, and parses the raw data according to the data parser to obtain the target data, the heterogeneous data aggregation unit aggregates the current timestamp, the device type of the BLE device, and the target data into a unified standard data frame based on a predetermined data frame format, and the distribution unit distributes the standard data frame to the corresponding channel according to the device type to send the standard data frame to the corresponding target platform. In this embodiment of the gateway device, the data carries the device type from the acquisition end, and the main control module automatically completes parsing, aggregation, and distribution according to the device type. It has strong multi-source heterogeneous data processing capabilities and does not require upper-layer applications to write code to distinguish data sources and parsing protocols, greatly reducing code redundancy.

[0042] In an optional embodiment, the acquisition module is an NFC card reader, the tag data is NFC tag data, and each BLE device is configured with corresponding NFC tag data; The NFC reader is used to read the NFC tag data after being touched by the BLE device, and to parse the NFC tag data to obtain the device type and the connection address.

[0043] Each BLE device is equipped with an independent NFC tag, which is a passive tag that does not require power and is configured with corresponding NFC tag data.

[0044] The connection address is the MAC address of the BLE device, and the gateway device connects to the BLE device based on the MAC address. The device type is represented by an enumeration code, such as 0x06 for vital signs, 0x07 for gestures, 0x08 for location, and 0x09 for power.

[0045] The NFC reader module on the gateway device side reads NFC tag data by touch and writes it to the local database; then the BLE central module of the gateway device uses the read MAC address to establish a long-term connection with the BLE device through the standard BLE protocol to transmit sensor data.

[0046] In this embodiment, the device type is pre-configured during the initial NFC configuration phase, the heterogeneous data source is structured, and the data carries semantic tags of the device type from the collection end. The main control module automatically completes parsing, aggregation and distribution according to the device type, and the upper layer application does not need to pay attention to the underlying data format, reducing code redundancy.

[0047] The NFC card reader module can be implemented using the ICM810N, the BLE central module can be implemented using the CC2340R53, and the matching and parsing unit, heterogeneous data aggregation unit and distribution unit in the main control module are implemented using C++-based software and run on the ARMLinux platform, further realizing the decoupling of software and hardware.

[0048] In an optional embodiment, the NFC tag data further includes scene parameters, which are used to adaptively process the business scenario corresponding to the target data. The scene parameters include at least reporting frequency, anomaly detection threshold, and local early warning rules. The distribution unit is specifically used to distribute the standard data frame to the corresponding channel according to the device type and the reporting frequency, so as to send the standard data frame to the corresponding target platform; The main control module also includes an anomaly warning unit, which is used to perform anomaly detection on the target data according to the anomaly detection threshold; if an anomaly is detected in the target data, an early warning is issued according to the local early warning rules.

[0049] The NFC tag data also includes pre-defined scenario parameters, at least including reporting frequency, anomaly detection threshold, and local early warning rules, to enable adaptive processing for corresponding business scenarios. Specifically, the scenario parameter vector in the NFC tag data is as follows: ; in, The reporting frequency of standard data frames; This is the threshold for anomaly detection; This is a local early warning rule.

[0050] In existing technologies, scene parameters are typically embedded in firmware before the device leaves the factory or set after deployment through complex software configuration interfaces. This prevents the same hardware device from flexibly adjusting its behavior according to changes in the deployment scenario, resulting in low deployment efficiency. This embodiment reads scene parameter vectors from NFC tag data. S Then, the system automatically configures the business scenarios or data pipeline behaviors of the target data, achieving one-touch configuration and scenario self-adaptation. It has strong business scenario adaptability and reduces the complexity of on-site scenario deployment.

[0051] For example, for vital sign monitoring in high-intensity exercise scenarios, the reporting frequency is set to high frequency (e.g., 10Hz), the anomaly detection threshold corresponds to a heart rate upper limit of 180bpm, and the local warning rule is 0x01, which corresponds to the rule of immediately triggering an audible and visual alarm when the heart rate exceeds the upper limit. For vital sign monitoring in daily scenarios, the reporting frequency is set to low frequency (e.g., 1Hz), the anomaly detection threshold corresponds to a heart rate upper limit of 100bpm, and the local warning rule is 0x02, which corresponds to the rule of only logging when the heart rate exceeds the upper limit. For monitoring in warehouse positioning scenarios, the reporting frequency is set to extremely low frequency (e.g., 0.5Hz), the anomaly detection threshold corresponds to an electronic fence radius of 100m, and the local warning rule is 0x03, which corresponds to the rule of triggering an audible and visual alarm when the boundary is crossed.

[0052] Furthermore, the scene parameters in the NFC tag data can be updated through the management terminal. If new NFC tag data is issued, the existing NFC tag data will be overwritten, and the scene parameters in the newly issued NFC tag data will be used to achieve controllable and dynamic adjustment of the scene parameters.

[0053] In an optional embodiment, the NFC tag data further includes a binding status parameter; the NFC reader is specifically used to read the NFC tag data after touching the BLE device, and to parse the NFC tag data to obtain the device type, the connection address, and the binding status parameter; if the binding status parameter is unbound, the BLE central module is triggered; otherwise, the BLE central module is not triggered.

[0054] Specifically, when a BLE device leaves the factory, the binding status parameter in the NFC tag data can be set to unbound. When it touches a gateway device, reading the unbound binding status parameter in the NFC tag data triggers the BLE central module, which then connects to the BLE device. After connection, it can send feedback to the management terminal so that a bound binding status parameter can be written into the NFC tag data, making the BLE device belong to that gateway device. If the binding status parameter in the NFC tag data is bound, the BLE central module will not be triggered, and therefore the BLE central module will not connect to the BLE device.

[0055] Existing NFC-BLE pairing schemes do not set binding status parameters, which makes it impossible for gateway devices to distinguish whether a BLE device has been used by a gateway device, or easily leads to connection conflicts in multi-gateway scenarios. This embodiment sets binding status parameters in the NFC tag data, allowing the gateway device to locally determine whether pairing is allowed during the touch phase, thereby achieving deduplication verification and preventing the same BLE device from being paired and used by different gateways, thus preventing connection conflicts in multi-gateway scenarios.

[0056] Figure 2 A schematic diagram of a multi-source heterogeneous BLE device data aggregation and processing system according to an embodiment of the present invention is shown. The system includes a management terminal, BLE devices, and a gateway device as described above. The management terminal is used to configure the tag data of the BLE devices. The management terminal can be developed based on Qt and is an application that runs independently on a PC or tablet, independent of the main control module of the gateway device. If the tag data is NFC tag data, the management terminal can be used for initial configuration of NFC tag data, device status monitoring, and system debugging, providing visualization support for testing. Furthermore, embodiments of the gateway device can be found in the above embodiments and will not be repeated here.

[0057] Figure 3 A flowchart of a data aggregation and processing method for multi-source heterogeneous BLE devices according to an embodiment of the present invention is shown, as follows: Figure 3 As shown, the method includes the following steps: Step 10: Obtain tag data of BLE devices. The tag data includes device type and connection address. The BLE devices include one or more, and the multiple BLE devices include various different device types. Step 20: Establish a connection with the BLE device based on the connection address, and receive the raw data sent by the BLE device; Step 30: Match the corresponding data parser according to the device type of the BLE device, and parse the original data according to the data parser to obtain the target data; Step 40: Based on the predetermined data frame format, the current timestamp, the device type of the BLE device, and the target data are aggregated into a unified standard data frame; Step 50: Distribute the standard data frame to the corresponding channel according to the device type, so as to send the standard data frame to the corresponding target platform.

[0058] The implementation methods for data aggregation and processing of multi-source heterogeneous BLE devices are basically the same as those for gateway devices, and can be referred to the above implementation methods.

[0059] This invention first acquires tag data from BLE devices, establishes a connection with the BLE devices based on their connection addresses, and receives raw data sent by the BLE devices. Then, it matches the corresponding data parser according to the device type of the BLE devices, parses the raw data using the data parser to obtain the target data, and aggregates the current timestamp, the device type of the BLE devices, and the target data into a unified standard data frame based on a predetermined data frame format. Finally, it distributes the standard data frame to the corresponding channel according to the device type to send the standard data frame to the corresponding target platform. In this invention, the data carries the device type from the acquisition end, and the parsing, aggregation, and distribution are automatically completed according to the device type. It has strong multi-source heterogeneous data processing capabilities and does not require upper-layer applications to write code to distinguish data sources and parsing protocols, greatly reducing code redundancy.

[0060] Figure 4 The diagram shows a structural schematic of an embodiment of the computer device of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the computer device.

[0061] like Figure 4 As shown, the computer device may include: a processor 402, a communications interface 404, a memory 406, and a communications bus 408.

[0062] The processor 402, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other computer devices, such as clients or other server network elements. The processor 402 executes program 410, specifically performing the relevant steps in the above method embodiments.

[0063] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0064] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The computer device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0065] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0066] Specifically, program 410 can be called by processor 402 to cause the computer device to perform the following operations: Acquire tag data of BLE devices, the tag data including device type and connection address, the BLE devices include one or more, and the multiple BLE devices include various different device types; Establish a connection with the BLE device based on the connection address, and receive raw data sent by the BLE device; Match the corresponding data parser according to the device type of the BLE device, and parse the original data according to the data parser to obtain the target data; Based on a predetermined data frame format, the current timestamp, the device type of the BLE device, and the target data are aggregated into a unified standard data frame; The standard data frame is distributed to the corresponding channel according to the device type, so as to send the standard data frame to the corresponding target platform.

[0067] This invention provides a computer-readable storage medium storing at least one executable instruction that, when executed on a computer device, causes the computer device to perform any of the above-described method embodiments.

[0068] This invention provides a computer program that can be invoked by a processor to cause a computer device to execute any of the above-described method embodiments.

[0069] This invention provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed on a computer, cause the computer to perform any of the above-described method embodiments.

[0070] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of the present invention are not directed to any particular programming language. It should be understood that the content of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0071] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0072] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the embodiments of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.

[0073] Those skilled in the art will understand that modules in the computer device of the embodiments can be adaptively modified and placed in one or more computer devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or computer device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0074] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A gateway device, characterized in that, The gateway device includes: The acquisition module is used to acquire tag data of BLE devices. The tag data includes at least the device type and connection address. The BLE devices include one or more, and the multiple BLE devices include various different device types. The BLE central module is used to establish a connection with the BLE device based on the connection address and to receive raw data sent by the BLE device. The main control module includes a matching and parsing unit, a heterogeneous data aggregation unit, and a distribution unit. The matching and parsing unit is used to match the corresponding data parser according to the device type of the BLE device, and parse the original data according to the data parser to obtain the target data. The heterogeneous data aggregation unit is used to aggregate the current timestamp, the device type of the BLE device, and the target data into a unified standard data frame based on a predetermined data frame format. The distribution unit is used to distribute the standard data frame to the corresponding channel according to the device type, so as to send the standard data frame to the corresponding target platform; The acquisition module is an NFC card reader, and the tag data is NFC tag data. Each BLE device is configured with corresponding NFC tag data, which also includes scene parameters and binding status parameters. The NFC reader is used to read the NFC tag data after touching the BLE device, and parse the NFC tag data to obtain the device type, the connection address, the scene parameters and the binding status parameters. If the binding status parameter is unbound, the BLE central module is triggered; otherwise, the BLE central module is not triggered. The scenario parameters are used to adaptively process the business scenario corresponding to the target data. The scenario parameters include at least the reporting frequency, the anomaly detection threshold, and the local early warning rules. The distribution unit is specifically used to distribute the standard data frame to the corresponding channel according to the device type and the reporting frequency, so as to send the standard data frame to the corresponding target platform; The main control module also includes an anomaly warning unit, which is used to perform anomaly detection on the target data according to the anomaly detection threshold; if an anomaly is detected in the target data, an early warning is issued according to the local early warning rules.

2. The gateway device according to claim 1, characterized in that, The data parser is a structure that includes a parsing template, physical quantity units, and scaling factors; The matching parsing unit is specifically used to take the original data as input parameters, call the member function of the data parser, and the member function extracts the physical quantity from the original data according to the parsing template in the structure, and generates the target data based on the physical quantity, the unit of the physical quantity and the scaling factor.

3. The gateway device according to claim 1, characterized in that, It also includes a list module, used to generate a device list based on the device type and the connection address, and store it in a preset database; The BLE central module is specifically used to establish connections with the corresponding BLE devices sequentially according to the connection addresses in the device list, using a delayed queue scheduling algorithm and a preset delay time slot.

4. A data aggregation and processing system for multi-source heterogeneous BLE devices, characterized in that, The system includes a management terminal, BLE devices, and a gateway device as described in any one of claims 1-3, wherein the management terminal is used to configure the tag data of the BLE devices.

5. A method for data aggregation and processing of multi-source heterogeneous BLE devices applied to a gateway device as described in any one of claims 1-3, characterized in that, The method includes: Acquire tag data of BLE devices, the tag data including device type and connection address, the BLE devices include one or more, and the multiple BLE devices include various different device types; Establish a connection with the BLE device based on the connection address, and receive raw data sent by the BLE device; Match the corresponding data parser according to the device type of the BLE device, and parse the original data according to the data parser to obtain the target data; Based on a predetermined data frame format, the current timestamp, the device type of the BLE device, and the target data are aggregated into a unified standard data frame; The standard data frame is distributed to the corresponding channel according to the device type, so as to send the standard data frame to the corresponding target platform; Specifically, tag data of BLE devices is acquired via an NFC reader. This tag data is NFC tag data, and each BLE device is configured with corresponding NFC tag data. The NFC tag data also includes scene parameters and binding status parameters. After the NFC reader touches the BLE device, it reads the NFC tag data and parses the NFC tag data to obtain the device type, the connection address, the scene parameters, and the binding status parameters. If the binding status parameter is "not bound", a connection is established with the BLE device based on the connection address; otherwise, no connection is established. The scenario parameters are used to adaptively process the business scenario corresponding to the target data. The scenario parameters include at least the reporting frequency, the anomaly detection threshold, and the local early warning rules. During distribution, the standard data frame is distributed to the corresponding channel according to the device type and the reporting frequency, so as to send the standard data frame to the corresponding target platform; Anomaly detection is performed on the target data according to the anomaly detection threshold; if anomalies are detected in the target data, an early warning is issued according to the local early warning rules.

6. A computer device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the method as described in claim 5.

7. A computer-readable storage medium, characterized in that, The storage medium stores at least one executable instruction, which, when executed on a computer device, causes the computer device to perform the method as described in claim 5.

Images