MQTT bidirectional topic adaptive parsing and routing method based on single configuration template

Abstract

This application provides a bidirectional adaptive parsing and routing method for MQTT topics based on a single configuration template, applicable to the Internet of Things (IoT) field. The method includes: reading a user-filled topic template string; recording the method for obtaining the actual variable values ​​required for each preset placeholder in the topic template string during uplink publishing, generating a first parsing rule; replacing the preset placeholders in the topic template string with preset MQTT wildcards to obtain a subscription topic; replacing each preset placeholder in the topic template string with a capture group, then replacing the capture group with an intermediate placeholder, escaping and restoring the capture group, compiling it into a regular expression object, generating a second parsing rule; during uplink data transmission, calling the first parsing rule to replace each preset placeholder in the topic template string with the obtained corresponding actual variable values ​​to generate a publishing topic; during downlink data transmission, calling the second parsing rule to perform regular expression matching and variable extraction on the topic string, constructing downlink data packets.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to an MQTT bidirectional Topic adaptive resolution and routing method based on a single configuration template. Background Technology

[0002] The MQTT (Message Queuing Telemetry Transport) protocol uses a hierarchical path string (e.g., gw / abc / device / 123 / object / 456 / rx) for topics. The Broker supports subscriptions using wildcards (+ for single-level matching, # for multi-level matching). IoT (Internet of Things) gateways typically need to handle topic processing in two directions simultaneously: • Uplink (Gateway → Cloud): When publishing a message, the gateway needs to encode information such as device identifier (e.g., DevEUI, Device ID) and data object identifier (e.g., ObjectID, ObjectName) into the Topic so that the cloud can route the message to different processing logic according to the Topic.

[0003] • Downlink (Cloud → Gateway): The gateway needs to subscribe to control commands from the cloud and extract the device identifier from the specific topic of the received message to determine the target device and data object of the command, and then route it to the corresponding device driver.

[0004] However, different IoT platforms have significantly different requirements for Topic formats. When a gateway connects to a new platform, it needs to modify the Topic-related code, which makes Topic configuration and parsing quite complicated. Summary of the Invention

[0005] The purpose of this application is to provide an MQTT bidirectional Topic adaptive resolution and routing method based on a single configuration template, so as to simplify the Topic configuration process. The specific technical solution is as follows: In a first aspect of this application, a method for adaptive resolution and routing of bidirectional MQTT topics based on a single configuration template is provided, the method comprising: When the system starts up or the forwarding service configuration is updated, read the Topic template string filled in by the user; Record the method for obtaining the actual variable values ​​required by each preset placeholder in the Topic template string during the upstream publication, and generate the first parsing rule; Replace the preset placeholders in the Topic template string with preset MQTT wildcards to obtain the subscription Topic, and submit the subscription Topic to the MQTT library to execute the subscription; Replace each of the preset placeholders in the Topic template string with a capture group, and then replace the capture group with an intermediate placeholder to obtain the first string; The first string is escaped and the capture group is restored to obtain the second string; The second string is compiled into a regular expression object and stored to generate the second parsing rule; When data is uploaded, the first parsing rule is invoked to obtain the actual variable values ​​corresponding to each preset placeholder according to the acquisition method. Each preset placeholder in the Topic template string is replaced with the obtained corresponding actual variable values ​​to generate a publishing Topic. The publishing Topic is then sent to the MQTT Broker. During data transmission, the second parsing rule is invoked to perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data. The downlink data packet is constructed based on the extracted variables and then sent to the target device.

[0006] In one possible implementation, the step of invoking the second parsing rule to perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data, and constructing the downlink data packet based on the extracted variables, includes: When the MQTT client receives a downlink message, it retrieves the Topic string from the downlink message; The second parsing rule is invoked to perform regular expression matching on the Topic string, extract the variables corresponding to the capture groups in the Topic string, and obtain each extracted variable; If an extracted variable representing the device serial number is found, determine whether the extracted variable is consistent with the device serial number; If not, then discard the Topic string; If so, then construct the downlink data packet based on the extracted variables described above.

[0007] In one possible implementation, the method further includes: If the devEUI variable is extracted, query the preset LoRa device table to obtain the device ID; If the device ID is not obtained, the devEUI variable is parsed into an integer and used as the device ID; If the objectID variable is extracted, the device ID of the device to which the object belongs is retrieved by querying the preset object table.

[0008] In one possible implementation, the step of invoking the first parsing rule and obtaining the actual variable values ​​corresponding to each of the preset placeholders according to the acquisition method includes: When the preset placeholder is $devEUI or $deveui, for LoRa devices, the preset LoRa device table is queried to obtain the HEX string corresponding to the device ID; for non-LoRa devices, the device name of the device is obtained. When the preset placeholder is $deviceName, query the device table to obtain the device service name; When the preset placeholder is $objectName, the object business name is retrieved by querying the object table.

[0009] In one possible implementation, the step of escaping the first string and restoring the capture group to obtain the second string includes: Perform QuoteMeta character escaping on the first string to obtain the intermediate string; Replace the string corresponding to the middle placeholder in the intermediate string with the capture group to obtain the second string.

[0010] In one possible implementation, sending the downlink data packet to the target device includes: If the device ID is obtained, the downlink data packet is routed to the device corresponding to that device ID; Otherwise, the downlink data packets are forwarded directly to the LoRa network layer.

[0011] In one possible implementation, the preset placeholders include at least $gatewaySN, $devEUI, $deveui, $deviceID, $objectID, $objectName, and $deviceName, and the preset MQTT wildcard is "+".

[0012] In a second aspect of this application, an MQTT bidirectional Topic adaptive resolution and routing device based on a single configuration template is provided, the device comprising: The initialization reading module is used to read the Topic template string filled in by the user when the system starts up or when the forwarding service configuration is updated; The first parsing rule generation module is used to record the method of obtaining the actual variable values ​​required by each preset placeholder in the Topic template string when publishing to the upstream, and to generate the first parsing rule. The Topic generation module is used to replace the preset placeholders in the Topic template string with preset MQTT wildcards to obtain the subscription Topic, and submit the subscription Topic to the MQTT library to execute the subscription; The first string generation module is used to replace each of the preset placeholders in the Topic template string with a capture group, and then replace the capture group with an intermediate placeholder to obtain the first string; The second string generation module is used to escape the first string and restore the capture group to obtain the second string; The second parsing rule generation module is used to compile the second string into a regular expression object for storage and generate the second parsing rule. The data uplink module is used to, when data is being uplinked, call the first parsing rule, obtain the actual variable values ​​corresponding to each of the preset placeholders according to the acquisition method, replace each preset placeholder in the Topic template string with the obtained corresponding actual variable values, generate a publishing Topic, and send the publishing Topic to the MQTT Broker; The downlink data module is used to call the second parsing rule during downlink data transmission, perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data, construct downlink data packets based on the extracted variables, and send the downlink data packets to the target device.

[0013] In one possible implementation, the data downlink module includes: The Topic string retrieval submodule is specifically used to retrieve the Topic string from the downlink message when the MQTT client receives the downlink message; The variable extraction submodule is specifically used to call the second parsing rule, perform regular expression matching on the Topic string, extract the variables corresponding to the capture group in the Topic string, and obtain each extracted variable; The serial number determination submodule is specifically used to determine whether the extracted variable representing the device serial number matches the local serial number when the extracted variable is found; if not, the Topic string is discarded. If so, then construct the downlink data packet based on the extracted variables described above.

[0014] In one possible implementation, the device further includes: The first module for obtaining the device ID is used to query the preset LoRa device table to obtain the device ID when the devEUI variable is extracted. The second module for obtaining the device ID is used to parse the devEUI variable into an integer and use it as the device ID if the device ID is not obtained. The third module for obtaining device ID is used to query a preset object table to obtain the device ID of the device to which the object belongs, provided that the objectID variable has been extracted.

[0015] In one possible implementation, the data uplink module includes: The first data filling submodule is specifically used to, when the preset placeholder is $devEUI or $deveui, query the preset LoRa device table to obtain the HEX string corresponding to the device ID for LoRa devices; and to obtain the device name for non-LoRa devices when the preset placeholder is $devEUI or $deveui. The second data filling submodule is specifically used to query the device table to obtain the device service name when the preset placeholder is $deviceName. The third submodule for data population is specifically used to query the object table to obtain the object business name when the preset placeholder is $objectName.

[0016] In one possible implementation, the second string generation module includes: The character escaping submodule is specifically used to perform QuoteMeta character escaping on the first string to obtain the intermediate string; The capture group restoration submodule is specifically used to replace the string corresponding to the middle placeholder in the intermediate string with the capture group to obtain the second string.

[0017] In one possible implementation, the data downlink module includes: The downlink data submodule is specifically used to route the downlink data packet to the device corresponding to the device ID when the device ID is obtained; Otherwise, the downlink data packets are forwarded directly to the LoRa network layer.

[0018] In one possible implementation, the preset placeholders include at least $gatewaySN, $devEUI, $deveui, $deviceID, $objectID, $objectName, and $deviceName, and the preset MQTT wildcard is "+".

[0019] In a third aspect of this application, an electronic device is provided, comprising: Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the method described in the first aspect of the embodiments of this application.

[0020] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements the method described in the first aspect of the present application.

[0021] Compared with the prior art, the embodiments of this application have at least the following technical effects: This application provides an MQTT bidirectional Topic adaptive resolution and routing method based on a single configuration template. The method includes: reading a Topic template string filled in by the user when the system starts or the forwarding service configuration is updated; recording the acquisition method of the actual variable values ​​required for each preset placeholder in the Topic template string during uplink publishing, and generating a first resolution rule; replacing the preset placeholders in the Topic template string with preset MQTT wildcards to obtain a subscription Topic, and submitting the subscription Topic to the MQTT library for subscription execution; replacing each preset placeholder in the Topic template string with a capture group, and then replacing the capture group with an intermediate placeholder to obtain a first string; and then... The first string is escaped and the capture group is restored to obtain the second string; the second string is compiled into a regular expression object and stored to generate a second parsing rule; when data is transmitted uplinked, the first parsing rule is called to obtain the actual variable values ​​corresponding to each preset placeholder according to the acquisition method, and each preset placeholder in the Topic template string is replaced with the obtained corresponding actual variable values ​​to generate a publishing Topic; the publishing Topic is sent to the MQTT Broker; when data is transmitted downlinked, the second parsing rule is called to perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data, and a downlink data packet is constructed based on the extracted variables and sent to the target device.

[0022] By applying the method of this application, users can configure only one Topic template string containing semantic variable placeholders. This template string is used for Topic subscription and regular expression parsing, ensuring both products are derived from the same template and remain consistent. When the format changes, only one configuration needs to be modified, simplifying the Topic configuration process. Furthermore, the system automatically recompiles both products from the same source, eliminating the risk of inconsistency. In addition, by replacing placeholders with capture groups, intermediate placeholders can record the position of capture groups. Escaping placeholders and restoring capture groups allows for complete escaping of literal parts in the regular expression while fully preserving capture groups, ensuring that the two do not interfere with each other.

[0023] Of course, implementing any method of the embodiments of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0024] 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, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0025] Figure 1 A flowchart of an MQTT bidirectional Topic adaptive resolution and routing method based on a single configuration template provided in an embodiment of this application; Figure 2 A timing diagram for Topic subscription provided in an embodiment of this application; Figure 3 This application provides a timing diagram for parsing a Topic string in an embodiment. Figure 4 A flowchart illustrating the construction of downlink data packets provided in embodiments of this application; Figure 5 A timing diagram provided in this application embodiment for uplink data publishing; Figure 6 A schematic diagram of a structure of an MQTT bidirectional Topic adaptive resolution and routing device based on a single configuration template provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0027] In the MQTT protocol, a Topic is a hierarchical path string (e.g., gw / abc / device / 123 / object / 456 / rx). The Broker supports subscriptions using wildcards (+ for single-level matching, # for multi-level matching). IoT (Internet of Things) gateways typically need to handle Topic processing in two directions simultaneously: Uplink (Gateway → Cloud): When publishing a message, the gateway needs to encode information such as device identifier (e.g., DevEUI, Device ID) and data object identifier (e.g., ObjectID, ObjectName) into the Topic so that the cloud can route the message to different processing logic according to the Topic.

[0028] Downlink (Cloud → Gateway): The gateway needs to subscribe to control commands from the cloud and extract the device identifier from the specific topic of the received message to determine the target device and data object of the command, and then route it to the corresponding device driver.

[0029] However, different IoT platforms (such as AWS IoT Core, Alibaba Cloud IoT, and self-built Broker) have significantly different requirements for Topic format. When the gateway connects to a new platform, it needs to modify the Topic-related code, which makes the configuration and parsing of Topics quite complicated.

[0030] In related technologies, the Topic format has the following configuration or parsing methods, and the applicant has found that each of them has different defects during use: Method A: Hard-coded Topic format.

[0031] In the gateway code, the Topic format is fixed, such as "gw / " + gatewaySN + " / device / " + devEUI + " / rx". The corresponding downstream subscription Topic is written as "gw / + / device / + / tx", and variables are extracted by string splitting (split by / and taking fields by position) when a message is received.

[0032] However, with this approach, if the second platform requiring integration specifies a Topic format of device / $devEUI / gateway / $gatewaySN / data (with a different field order), the code must be modified and recompiled and deployed. If the gateway integrates with five platforms of different formats simultaneously, five independent branches for Topic construction and parsing must be maintained, with the code size increasing linearly with the number of platforms. If a platform upgrades its Topic format, the corresponding code branch must be manually modified synchronously; missing even one modification will result in the interruption of bidirectional communication.

[0033] Method B: Configure uplink templates and downlink regular expressions independently.

[0034] Two separate configuration items are provided: one for the template string used for uplink publishing (e.g., gw / $gatewaySN / device / $devEUI / rx), and the other for the regular expression used for downlink parsing (e.g., gw / (\w+) / device / (\w+) / tx), which are filled in by the user. The system performs string replacement during uplink and uses regular expression matching during downlink.

[0035] Applying this method requires users to maintain two semantically highly related configuration items simultaneously (uplink template + downlink regular expression). An error in either location will cause communication failure, and the error is difficult to locate (when the uplink topic and the downlink subscribed topic do not match, there is no runtime error, only silent message loss). In actual testing, after configuring gw / $gatewaySN / device / $devEUI / rx as the uplink template, the user omitted the gateway SN capture group in the downlink regular expression, resulting in an empty downlink device ID extraction, making routing impossible, and the troubleshooting took more than 2 hours.

[0036] Method C: Configure only the subscription wildcard Users configure only one subscription Topic containing the '+' wildcard (e.g., gw / + / device / + / tx). Upon receiving a message, the downstream system extracts the field value based on the location index of the '+' wildcard (e.g., the second segment is the gateway SN, and the fourth segment is devEUI). The upstream Topic is concatenated separately in the code and is unrelated to the downstream configuration.

[0037] Therefore, when the Topic level changes (such as when the platform adds a new prefix layer v2 / gw / + / ...), all position indexes need to be adjusted synchronously, causing a ripple effect. Furthermore, position indexes cannot express the semantics of "whether a certain layer is a device ID or DevEUI," and the meaning of variables depends on documentation conventions, resulting in poor code readability and maintainability. Moreover, the construction of upstream Topics still needs to be implemented independently, with no inherent consistency constraints between upstream and downstream parsing.

[0038] To address at least one of the aforementioned problems, a first aspect of this application provides a method for adaptive resolution and routing of MQTT bidirectional topics based on a single configuration template, the method comprising: Figure 1 The steps shown are as follows: Step S101: When the system starts up or the forwarding service configuration is updated, read the Topic template string filled in by the user.

[0039] In practical applications, when the system starts up or the forwarding service configuration is updated, the system enters the initialization phase. It parses the Topic template string filled in by the user to obtain the subscription Topic and regular expression objects. This system is a communication system supporting the MQTT protocol and may include devices such as the cloud and client devices to implement asynchronous message routing based on topics. The client device can be a gateway device or other terminal device. In one example, the client device is used to publish collected data (such as temperature and status) to a specified Topic, with optional subscription control commands; the cloud provides the MQTTBroker service, receiving all client messages and routing them to subscribers by Topic.

[0040] Forwarding service configuration refers to the policy settings in the MQTT Broker used to define message routing rules, determining how data published by a device is distributed to the corresponding subscribers. This configuration can include information such as Topic routing rules, access control, data filtering, and protocol conversion.

[0041] The user-filled Topic template string refers to the user filling in the string according to the pre-set Topic template during the initialization phase. This template specifies the types and formats of characters included in the Topic string, so that the gateway device or other client devices will construct the Topic according to the template when sending the Topic uplink.

[0042] Step S102: Record how the actual variable values ​​required for each preset placeholder in the Topic template string are obtained when publishing upstream, and generate the first parsing rule.

[0043] In this embodiment, the preset placeholder can be a placeholder containing semantic variables. For example, the preset placeholder may include $gatewaySN, $devEUI, $deveui, $deviceID, $objectID, $objectName, and $deviceName. $gatewaySN represents the local serial number, which can be obtained through local reading. $devEUI and $deveui represent the unique identifier of the device in the IoT platform within LoRaWAN (Long Range Wide Area Network), i.e., the device ID, used for LoRa terminal network access authentication. $deviceID represents the unique client identifier assigned to the device by the IoT platform in the MQTT protocol, used for authentication and message routing during MQTT connection. In practical applications, the values ​​of $devEUI, $deveui, and $deviceID can be the same.

[0044] $objectID represents the numeric ID of an object, which can be a logical entity record in the IoT platform, such as a device instance, data packet, or application resource. The numeric ID is a unique primary key generated internally by the platform for database indexing or fast retrieval. $objectName represents the business name, which can be a unique identifier or path for a specific "object" instance in the software system; $deviceName represents the device name of the hardware device.

[0045] The method for obtaining the actual variable values ​​corresponding to each preset placeholder can be predefined. In one example, for the preset placeholders $devEUI and $deveui, for LoRa devices, the hexadecimal uppercase string (HEX string) can be retrieved from the LoRa device table as the actual variable value; for non-LoRa devices, the device name is used as the actual variable value. For the preset placeholder $objectName, the service name corresponding to the object can be retrieved from the object table. For the preset placeholder $deviceName, the device name can be retrieved from the device table.

[0046] Step S103: Replace the preset placeholders in the Topic template string with preset MQTT wildcards to obtain the subscription Topic, and submit the subscription Topic to the MQTT library to execute the subscription.

[0047] The default wildcard in MQTT is "+". For example, if the Topic template string is: gw / $gatewaySN / device / $devEUI / object / $objectID / rx, then replacing the default placeholder with "+" will result in the subscription Topic: gw / + / device / + / object / + / rx. After submitting the subscription Topic to the MQTT library and executing the subscription, the MQTT subscription mechanism can forward messages sent by the publisher that match the Topic to the client.

[0048] Step S104: Replace each preset placeholder in the Topic template string with a capture group, and then replace the capture group with an intermediate placeholder to obtain the first string.

[0049] Capture groups can be generated using parentheses "()", for example, replacing the preset placeholder "$gatewaySN" with the capture group "(?P <gatewaysn>Taking the Topic template string "gw / $gatewaySN / device / $devEUI / object / $objectID / rx" as an example, after replacing the capture group, we get: gw / (?P <gatewaysn>\w+) / device / (?P <deveui>\w+) / object / (?P <objectid>`\w+) / rx;` Then replace the capture group with a middle placeholder. In one example, the middle placeholder is `<<`. <capture>>>. Using the example above, the first string would be: gw / << <capture>>> / device / << <capture>>> / object / << <capture>>> / rx.

[0050] Step S105: Escape the first string and restore the capture group to obtain the second string.

[0051] The process involves first literal escaping of the first string, then replacing the middle placeholder with the capture group to obtain the second string. In one possible implementation, the first string is escaped using QuoteMeta (a function for escaping metacharacters) to obtain an intermediate string; the string corresponding to the middle placeholder in the intermediate string is then replaced with the capture group to obtain the second string.

[0052] In the method of this application embodiment, the QuoteMeta function scans the input string, identifies specific predefined characters, and inserts a backslash before them for escaping. For example, if the Topic template string contains special characters such as "." and "-", after QuoteMeta character escaping, they can be escaped as "\." and "\-". Taking the above example, for "gw / << <capture>>> / device / << <capture>>> / object / << <capture>After escaping and restoring the capture group of ">> / rx", the second string is "gw / (?P <gatewaysn>\w+) / device / (?P <deveui>\w+) / object / (?P <objectid>\w+) / rx”.

[0053] Step S106: Compile the second string into a regular expression object and store it to generate the second parsing rule.

[0054] The second parsing rule is used to implement the placeholder replacement, capture group restoration and other steps in steps S104-S106 until a regular expression object is generated.

[0055] Step S107: When data is being uploaded, the first parsing rule is invoked to obtain the actual variable values ​​corresponding to each preset placeholder according to the acquisition method. Each preset placeholder in the Topic template string is replaced with the obtained corresponding actual variable values ​​to generate the publishing Topic. The publishing Topic is then sent to the MQTT Broker.

[0056] Step S108: When data is being sent down, the second parsing rule is invoked to perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data. The downlink data packet is constructed based on the extracted variables and sent to the target device.

[0057] After the Topic is published to the MQTT Broker, MQTT can send the message to client devices that have subscribed to the corresponding Topic. In practice, the Topic template string can also include a `requestTopic` field, allowing the system to automatically subscribe to the management Topic and register a dedicated message handler (rather than a downlink router) when the MQTT connection is successful (in the `onConnected` callback). Upon receiving a Request message, a list of all enabled devices and objects under the current forwarding service is constructed and published to the `responseTopic`. For example, such as... Figure 2 As shown, when the connection is successful, the MQTT client can automatically subscribe to the management topic when subscribing to the downlink topic from the broker. Upon the arrival of a request message, it queries the database for all enabled devices and objects, and constructs a response topic based on the device list returned by the database, publishing it to the broker. This allows the cloud platform to proactively retrieve the device list after the gateway goes online, achieving automatic device discovery without requiring manual configuration of the cloud device list.

[0058] In practical applications, the method of this application embodiment can be applied not only to the MQTT protocol, but also to any message protocol or communication framework that supports wildcard subscription and requires the extraction of variables from topics / paths. Specifically, this use case must simultaneously meet the following conditions: 1. The message routing key (Topic / Queue / URI / RoutingKey) is a structured path string containing semantic variable segments; 2. The receiver needs to subscribe to a type of message using wildcards and extract variables from the routing key of the specific message for subsequent processing; 3. The routing key format is configured by the user, rather than being fixed in the code.

[0059] In one example, Figure 3 This is a sequence diagram illustrating the parsing of a Topic string according to an embodiment of this application. During the initialization phase, the user configures the Topic template string and submits it to the initialization module. The initialization module generates a subscription Topic from this string and submits it to the Broker via an MQTT client for subscription. It also compiles and performs regular expression matching on the Topic template string using a regular expression engine to generate a second parsing rule, and stores the generated regular expression object.

[0060] During the data downlink process, when the Broker sends a message to the MQTT client, it performs regular expression matching on the Topic string in the message according to the second parsing rule and validates the extracted variables. Then, it routes the message to the device driver based on the extracted device ID.

[0061] During the data uplink process, the device driver sends uplink data, the initialization module calls the first parsing rule to perform database lookup and filling of each variable, writes it into the Topic template string, generates the Topic to publish, and publishes it to the Broker.

[0062] By applying the method of this application, users can configure only one Topic template string containing semantic variable placeholders. This template string is used for Topic subscription and regular expression parsing, ensuring both products are derived from the same template and remain consistent. When the format changes, only one configuration needs to be modified, simplifying the Topic configuration process. Furthermore, the system automatically recompiles both products from the same source, eliminating the risk of inconsistency. In addition, by replacing placeholders with capture groups, intermediate placeholders can record the position of capture groups. Escaping placeholders and restoring capture groups allows for complete escaping of literal parts in the regular expression while fully preserving capture groups, ensuring that the two do not interfere with each other.

[0063] In one possible implementation, during data downlink, the downlink data packet construction in step S108 can be achieved through the following steps: Step 1: When the MQTT client receives a downlink message, obtain the Topic string from the downlink message.

[0064] Step 2: Call the second parsing rule to perform regular expression matching on the Topic string, extract the variables corresponding to the capture groups in the Topic string, and obtain each extracted variable.

[0065] Step 3: If the extracted variable representing the device serial number is found, determine whether the extracted variable is consistent with the local serial number; if not, discard the Topic string; if yes, construct the downlink data packet based on the extracted variables.

[0066] Furthermore, the method in this application embodiment may also include: Step 1: After extracting the devEUI variable, query the preset LoRa device table to obtain the device ID.

[0067] Step 2: If the device ID is not obtained, the devEUI variable is parsed into an integer and used as the device ID.

[0068] Step 3: If the objectID variable is extracted, query the preset object table to obtain the device ID of the device to which the object belongs.

[0069] The preset LoRa device table is a communication protocol layer data table designed for LoRa / LoRaWAN communication devices. It records network identity and parameter configuration fields such as devEUI variables and gateway IDs for device network access, communication control, and network operation and maintenance. The preset object table records core fields describing entity attributes, including but not limited to objectID and devEUI variables. When the objectID variable is extracted during Topic string extraction, the preset object table can be queried using objectID to obtain the devEUI variable of the device corresponding to that object, thus obtaining the device ID of the device to which the object belongs. In this embodiment, steps 3 and 1-2 are not executed sequentially, but rather selected based on the type of the obtained device identifier. For details, please refer to [reference needed]. Figure 4 The steps are shown.

[0070] First, upon receiving a downlink message from the MQTT client (e.g., a control command from the cloud), the Topic string is retrieved. For example, if the retrieved Topic string is: gw / SN001 / device / A1, the second parsing rule is invoked to perform regular expression matching. The extracted capture group and its corresponding variables are: gatewaySN=SN001, devEUI=A1B2C3D4, objectID=99.

[0071] If the gatewaySN is extracted, it is determined whether its (SN001) matches the serial number of the local machine. If they do not match, the message is considered not a local message and is silently discarded to prevent messages from other gateways from being misprocessed. If the serial numbers match, the device identifier type is determined. If the devEUI variable is extracted, the device ID recorded in the preset LoRa device table is retrieved. If the device ID is not retrieved, the query fails, the devEUI variable is parsed into an integer, and used as the device ID (in this embodiment, the non-standard usage of directly writing the device ID into the devEUI field is compatible). In another case, if the objectID variable is extracted, the preset object table can be queried to obtain the device ID of the device to which the object recorded in the preset object table belongs.

[0072] After obtaining the device ID, a standardized downlink data packet is constructed based on the extracted variables (device ID, object ID, etc.) and sent to the device driver downlink channel.

[0073] When routing downlink data packets, routing can be done either to a single device based on the device ID or to a multicast channel. In one possible implementation, if the device ID is obtained, the downlink data packet is routed to the device corresponding to that device ID; otherwise, the downlink data packet is directly forwarded to the LoRa network layer (LoRaWAN multicast channel). For example, when configuring the Topic template string, an additional multicast downlink Topic configuration item (which may or may not include variable placeholders) can be supported. Upon receiving a multicast message, the device ID is not extracted; it is directly broadcast to the LoRa network layer.

[0074] By applying the method of this application embodiment, different extraction methods are implemented for different variables, and by recognizing the two device identification systems devEUI and deviceID, the method of this application embodiment can cover both LoRa and non-LoRa devices, thus expanding the application scope.

[0075] In one possible implementation, before device data is uploaded, semantic variables can be populated to construct the publishing topic. In one example, the construction of a publishing topic can be achieved through the following steps: 1. Construct an uplink Topic population context based on the device information of the current data packet.

[0076] The actual variable values ​​corresponding to each preset placeholder can be obtained in the following ways: $gatewaySN: Directly retrieves the local gateway serial number (obtained locally, no database lookup required).

[0077] $devEUI / $deveui: Query the default LoRa device table. If it is a LoRa device, take the hexadecimal uppercase string of DevEUI; if it is a non-LoRa device such as BACnet / Modbus, replace it with the device name (thereby ensuring that non-LoRa devices can also use the template containing $devEUI without having to maintain an independent template for each type of device).

[0078] `$deviceName`: Queries the device table to retrieve the device service name. The device service name refers to the name set by the user based on actual business needs, such as `device-test`. The device table records device information such as device name, device ID, and device type.

[0079] $objectID: Retrieves the numeric ID of the data object and converts it to a string; in FULL mode (full device reporting), fill in the fixed value No_Object.

[0080] $objectName: Retrieves the object's business name from the object table; in FULL mode, enter No_Object. The object's business name is a user-defined name based on actual business needs, such as object-test.

[0081] 2. Perform multiple string replacements (non-regular expressions) on the user-configured Topic template string, replacing each placeholder with the corresponding value in the context to generate the final published Topic. That is, write the actual variable values ​​into the Topic template string.

[0082] 3. Publish the data payload (the valid data part) along with the generated topic to the MQTT Broker.

[0083] like Figure 5 The diagram shows the timing of uplink data publishing in this embodiment. The data processor sends an uplink request carrying the device ID (42) and object ID (99) to the Topic filler. The Topic filler queries the device table through the database query module and obtains that the device type is LoRa device and the device name is temperature sensor A. Then, it queries the preset LoRa device table to obtain the DevEUI variable (DevEUI=A1B2C3D4E5F60001) and queries the object table to obtain the object name. After obtaining the variables, the filling context completely replaces the placeholders in the Topic template string to generate the publishing Topic. For example, the Topic template string is: gw / $gatewaySN / $devEUI / $objectName / rx. After replacing the placeholders, the publishing Topic is: gw / GW-SN001 / A1B2C3D4E5F60001 / Temperature / rx. It is sent to the MQTT client, and the MQTT client publishes it to the Broker.

[0084] In this embodiment of the application, for each placeholder, the upward padding and downward extraction can be performed using the content shown in Table 1 below: Table 1

[0085] Applying the method of this application embodiment, during uplink publishing, the system automatically queries the database to populate $deviceName (device service name) and $objectName (object service name), enabling the Topic to directly carry business semantics without requiring the cloud to look up the device name. Furthermore, the $devEUI variable is differentiated: for LoRa devices, the DevEUI hexadecimal string is used; for non-LoRa devices (BACnet / Modbus / KNX, etc.), the device name is used instead, ensuring that the same template is usable for all device types.

[0086] In a second aspect of this application, an MQTT bidirectional Topic adaptive resolution and routing device based on a single configuration template is provided. The device includes... Figure 6 The structure shown is as follows: The initialization reading module 601 is used to read the Topic template string filled in by the user when the system starts up or the forwarding service configuration is updated.

[0087] The first parsing rule generation module 602 is used to record how the actual variable values ​​required by each preset placeholder in the Topic template string are obtained when the document is published upstream, and to generate the first parsing rule.

[0088] The Topic generation module 603 is used to replace the preset placeholders in the Topic template string with preset MQTT wildcards to obtain the subscription Topic, and submit the subscription Topic to the MQTT library to execute the subscription.

[0089] The first string generation module 604 is used to replace each preset placeholder in the Topic template string with a capture group, and then replace the capture group with an intermediate placeholder to obtain the first string.

[0090] The second string generation module 605 is used to escape the first string and restore the capture group to obtain the second string.

[0091] The second parsing rule generation module 606 is used to compile the second string into a regular expression object for storage and generate the second parsing rule.

[0092] The data uplink module 607 is used to call the first parsing rule when data is uplinked, obtain the actual variable values ​​corresponding to each preset placeholder according to the acquisition method, replace each preset placeholder in the Topic template string with the obtained corresponding actual variable values, generate the publishing Topic, and send the publishing Topic to the MQTT Broker.

[0093] The downlink data module 608 is used to call the second parsing rule during downlink data transmission, perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data, construct downlink data packets based on the extracted variables, and send the downlink data packets to the target device.

[0094] In one possible implementation, the data downlink module includes: The Topic string retrieval submodule is specifically used to retrieve the Topic string from a downlink message when the MQTT client receives the downlink message. The variable extraction submodule is specifically used to call the second parsing rule, perform regular expression matching on the Topic string, extract the variables corresponding to the capture groups in the Topic string, and obtain each extracted variable. The serial number determination submodule is specifically used to determine whether the extracted variable representing the device serial number matches the local serial number when the extracted variable is found; if not, the Topic string is discarded. If so, then construct the downlink data packet based on each extracted variable.

[0095] In one possible implementation, the device further includes: The first module for obtaining the device ID is used to query the preset LoRa device table to obtain the device ID when the devEUI variable is extracted. The second module for obtaining the device ID is used to parse the devEUI variable into an integer and use it as the device ID if the device ID is not obtained. The third module for obtaining device ID is used to query a preset object table to obtain the device ID of the device to which the object belongs, provided that the objectID variable has been extracted.

[0096] In one possible implementation, the data uplink module includes: The first submodule for data population is specifically used to query the preset LoRa device table to obtain the HEX string corresponding to the device ID when the preset placeholder is $devEUI or $deveui; and to obtain the device name of the device when it is a non-LoRa device. The second submodule for data population is specifically used to query the device table to obtain the device service name when the preset placeholder is $deviceName. The third submodule for data population is specifically used to query the object table to obtain the object's business name when the preset placeholder is $objectName.

[0097] In one possible implementation, the second string generation module includes: The character escaping submodule is specifically used to perform QuoteMeta character escaping on the first string to obtain the intermediate string; The capture group restoration submodule is specifically used to replace the string corresponding to the middle placeholder in the intermediate string with the capture group to obtain the second string.

[0098] In one possible implementation, the data downlink module includes: The downlink data submodule is specifically used to route downlink data packets to the device corresponding to the device ID when the device ID is obtained. Otherwise, the downlink data packets are forwarded directly to the LoRa network layer.

[0099] In one possible implementation, the preset placeholders include at least $gatewaySN, $devEUI, $deveui, $deviceID, $objectID, $objectName, and $deviceName, and the preset MQTT wildcard is "+".

[0100] In a third aspect of the embodiments of this application, an electronic device is provided, see [link to relevant documentation]. Figure 7 ,include: Memory 701 is used to store computer programs; Processor 702, when executing a program stored in memory, implements: When the system starts up or the forwarding service configuration is updated, read the Topic template string filled in by the user; Record how the actual variable values ​​required for each preset placeholder in the Topic template string are obtained during the upstream publishing process, and generate the first parsing rule; Replace the preset placeholders in the Topic template string with preset MQTT wildcards to obtain the subscription Topic, and submit the subscription Topic to the MQTT library to execute the subscription; Replace each preset placeholder in the Topic template string with a capture group, and then replace the capture group with an intermediate placeholder to obtain the first string; The first string is escaped and the capture group is restored to obtain the second string; The second string is compiled into a regular expression object and stored to generate the second parsing rule; When data is uploaded, the first parsing rule is invoked to obtain the actual variable values ​​corresponding to each preset placeholder according to the acquisition method. The preset placeholders in the Topic template string are replaced with the obtained corresponding actual variable values ​​to generate the publishing Topic. The publishing Topic is then sent to the MQTT Broker. During data transmission, the second parsing rule is invoked to perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data. The downlink data packet is constructed based on the extracted variables and then sent to the target device.

[0101] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0102] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0103] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0104] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0105] In a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the method of the first aspect of the embodiments of this application.

[0106] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to implement the method of the first aspect of the embodiments of this application.

[0107] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0108] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0109] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. Related parts can be found in the descriptions of the system embodiments.

[0110] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.< / objectid> < / deveui> < / gatewaysn> < / capture> < / capture> < / capture> < / capture> < / capture> < / capture> < / capture> < / objectid> < / deveui> < / gatewaysn> < / gatewaysn>

Claims

1. A method for adaptive resolution and routing of bidirectional MQTT topics based on a single configuration template, characterized in that, The method includes: When the system starts up or the forwarding service configuration is updated, read the Topic template string filled in by the user; Record the method for obtaining the actual variable values ​​required by each preset placeholder in the Topic template string during the upstream publication, and generate the first parsing rule; Replace the preset placeholders in the Topic template string with preset MQTT wildcards to obtain the subscription Topic, and submit the subscription Topic to the MQTT library to execute the subscription; Replace each of the preset placeholders in the Topic template string with a capture group, and then replace the capture group with an intermediate placeholder to obtain the first string; The first string is escaped and the capture group is restored to obtain the second string; The second string is compiled into a regular expression object and stored to generate the second parsing rule; When data is uploaded, the first parsing rule is invoked to obtain the actual variable values ​​corresponding to each preset placeholder according to the acquisition method. Each preset placeholder in the Topic template string is replaced with the obtained corresponding actual variable values ​​to generate a publishing Topic. The publishing Topic is then sent to the MQTT Broker. During data transmission, the second parsing rule is invoked to perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data. The downlink data packet is constructed based on the extracted variables and then sent to the target device.

2. The method according to claim 1, characterized in that, The step of invoking the second parsing rule to perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data, and constructing the downlink data packet based on the extracted variables, includes: When the MQTT client receives a downlink message, it retrieves the Topic string from the downlink message; The second parsing rule is invoked to perform regular expression matching on the Topic string, extract the variables corresponding to the capture groups in the Topic string, and obtain each extracted variable; If an extracted variable representing the device serial number is found, determine whether the extracted variable is consistent with the device serial number; If not, then discard the Topic string; If so, then construct the downlink data packet based on the extracted variables described above.

3. The method according to claim 2, characterized in that, The method further includes: If the devEUI variable is extracted, query the preset LoRa device table to obtain the device ID; If the device ID is not obtained, the devEUI variable is parsed into an integer and used as the device ID; If the objectID variable is extracted, the device ID of the device to which the object belongs is retrieved by querying the preset object table.

4. The method according to claim 1, characterized in that, The step of invoking the first parsing rule and obtaining the actual variable values ​​corresponding to each preset placeholder according to the acquisition method includes: When the preset placeholder is $devEUI or $deveui, for LoRa devices, the preset LoRa device table is queried to obtain the HEX string corresponding to the device ID; for non-LoRa devices, the device name of the device is obtained. When the preset placeholder is $deviceName, query the device table to obtain the device service name; When the preset placeholder is $objectName, the object business name is retrieved by querying the object table.

5. The method according to claim 1, characterized in that, The step of escaping the first string and restoring the captured group to obtain the second string includes: Perform QuoteMeta character escaping on the first string to obtain the intermediate string; Replace the string corresponding to the middle placeholder in the intermediate string with the capture group to obtain the second string.

6. The method according to claim 3, characterized in that, Sending the downlink data packet to the target device includes: If the device ID is obtained, the downlink data packet is routed to the device corresponding to that device ID; Otherwise, the downlink data packets are forwarded directly to the LoRa network layer.

7. The method according to claim 1, characterized in that, The preset placeholders include at least $gatewaySN, $devEUI, $deveui, $deviceID, $objectID, $objectName, and $deviceName, and the preset MQTT wildcard is "+".

8. A bidirectional MQTT Topic adaptive resolution and routing device based on a single configuration template, characterized in that, The device includes: The initialization reading module is used to read the Topic template string filled in by the user when the system starts up or when the forwarding service configuration is updated; The first parsing rule generation module is used to record the method of obtaining the actual variable values ​​required by each preset placeholder in the Topic template string when publishing to the upstream, and to generate the first parsing rule. The Topic generation module is used to replace the preset placeholders in the Topic template string with preset MQTT wildcards to obtain the subscription Topic, and submit the subscription Topic to the MQTT library to execute the subscription; The first string generation module is used to replace each of the preset placeholders in the Topic template string with a capture group, and then replace the capture group with an intermediate placeholder to obtain the first string; The second string generation module is used to escape the first string and restore the capture group to obtain the second string; The second parsing rule generation module is used to compile the second string into a regular expression object for storage and generate the second parsing rule. The data uplink module is used to, when data is being uplinked, call the first parsing rule, obtain the actual variable values ​​corresponding to each of the preset placeholders according to the acquisition method, replace each preset placeholder in the Topic template string with the obtained corresponding actual variable values, generate a publishing Topic, and send the publishing Topic to the MQTT Broker; The downlink data module is used to call the second parsing rule during downlink data transmission, perform regular expression matching and variable extraction on the Topic string corresponding to the downlink data, construct downlink data packets based on the extracted variables, and send the downlink data packets to the target device.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images