Cross-platform intelligent lamp control APP system based on MQTT protocol

Abstract

The application provides a cross-platform intelligent lamp control APP system based on an MQTT protocol, relates to the technical field of smart home control, and receives an access request set of intelligent lamps under different operating system platforms, which contains device identification, platform type and control capability description information; performs access adaptation processing based on the MQTT protocol to obtain a cross-platform access adaptation result; generates a unified control instruction template applicable to all accessed lamps; converts the unified control instruction template into an MQTT format control message and sends the control message to the lamps; and receives instruction execution feedback messages returned by the lamps, so that efficient unified control of cross-platform intelligent lamps is achieved, and the convenience and compatibility of control are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of smart home control, in particular to a cross-platform smart lamp control APP system based on MQTT protocol. BACKGROUND

[0002] In the current rapid development of smart home, as an important part of the smart home system, the control method and management efficiency of smart lamps are of great concern. With the popularity of different operating system platforms such as iOS, Android and various embedded operating systems, a large number of smart lamps based on different platforms have emerged in the market. These cross-platform smart lamps have certain commonality in function and control requirements, but due to the differences in operating system platforms, their access methods and control instruction formats are different.

[0003] Traditional smart lamp control methods are often customized and developed for a single platform, lacking unified management and control capabilities for cross-platform smart lamps. When users have smart lamps from different platforms, they need to use different platform-specific control applications for operation, which not only increases the user's use cost and learning difficulty, but also makes it difficult to coordinate the control between different lamps. In addition, the traditional method usually needs to develop specific access modules for each platform when dealing with cross-platform access, which has low code reusability and low development efficiency, and is difficult to meet the increasingly diversified market demand and rapid iteration of product update requirements. SUMMARY

[0004] In view of the above-mentioned problems, in combination with the first aspect of the present application, the embodiments of the present application provide a cross-platform smart lamp control APP system based on MQTT protocol, the method comprising:

[0005] Receiving an access request set of cross-platform smart lamps, the access request set of cross-platform smart lamps containing device identification information, platform type information and control capability description information sent by smart lamps under different operating system platforms;

[0006] Based on the MQTT protocol, the access request set of the cross-platform smart lamps is subjected to access adaptation processing, and the corresponding MQTT message format rule is matched according to the platform type information to obtain a cross-platform access adaptation result;

[0007] According to the cross-platform access adaptation result and the control capability description information, a unified control instruction template suitable for all access smart lamps is generated, the unified control instruction template containing lamp state adjustment dimensions and corresponding adjustment instruction fields;

[0008] transforming the unified control instruction template into an MQTT format control message according to the MQTT message format rule, the MQTT format control message comprising a topic field, a payload field and a QoS level field, and the payload field embedding the content of the unified control instruction template;

[0009] sending the MQTT format control message to a corresponding cross-platform smart lamp, and receiving an instruction execution feedback message returned by the cross-platform smart lamp, the instruction execution feedback message being encapsulated according to the MQTT protocol format and comprising an execution state identifier and lamp current state information.

[0010] In still another aspect, the embodiment of the present application also provides a cross-platform smart lamp control APP system based on the MQTT protocol, comprising a processor and a machine readable storage medium, the machine readable storage medium being connected with the processor, the machine readable storage medium being used for storing programs, instructions or codes, and the processor being used for executing the programs, instructions or codes in the machine readable storage medium to realize the method described above.

[0011] Based on the above aspects, the embodiment of the present application realizes efficient adaptation of cross-platform access by receiving an access request set comprising smart lamp device identifiers, platform types and control capability descriptions under different operating system platforms, performing access adaptation processing on the access request set based on the MQTT protocol, and matching corresponding message format rules according to the platform types, effectively solves the compatibility problem caused by differences in different platform access modes, generates a unified control instruction template according to the access adaptation result and the control capability description, covers lamp state adjustment dimensions and corresponding adjustment instruction fields, so that the control instruction for different platform smart lamps has consistency and universality, greatly simplifies the control process, transforms the unified control instruction template into an MQTT format control message, encapsulates the topic, payload and QoS level fields according to the protocol specification, finally sends the MQTT format control message and receives the instruction execution feedback message returned by the lamp, realizes real-time monitoring and state feedback of the cross-platform smart lamp, and significantly improves the convenience, compatibility and reliability of the cross-platform smart lamp control. BRIEF DESCRIPTION OF DRAWINGS

[0012] Figure 1 is an execution flow diagram of the cross-platform smart lamp control method based on the MQTT protocol provided by the embodiment of the present application.

[0013] Figure 2 is a schematic diagram of exemplary hardware and software components of the cross-platform smart lamp control APP system based on the MQTT protocol provided by the embodiment of the present application. DETAILED DESCRIPTION

[0014] The present application will be described in detail below with reference to the accompanying drawings.Figure 1 is a flowchart of a cross-platform intelligent lamp control method based on an MQTT protocol provided by an embodiment of the present application. The cross-platform intelligent lamp control method based on the MQTT protocol will be described in detail below.

[0015] Step S110: receiving a set of access requests of cross-platform intelligent lamps, the set of access requests of cross-platform intelligent lamps containing device identification information, platform type information and control capability description information sent by intelligent lamps under different operating system platforms.

[0016] In a smart home scenario, there are various intelligent lamps, and these lamps run different operating systems. When these intelligent lamps complete initialization and are connected to a network, they can initiate an access request to a control APP system. Request information sent by intelligent lamps of different operating systems is gathered together to form a set of access requests.

[0017] Among them, the device identification information is an identification unique to each intelligent lamp, which is used to distinguish different lamps in the system. The platform type information explicitly indicates the operating system running on the lamp, such as some lamps based on the Android system, some based on the iOS system, and some based on the Linux system. The control capability description information details the functions that the lamp can implement, such as the range of brightness adjustment, the type of switchable color temperature, and the supported color change mode.

[0018] Step S111: listening to access request data from intelligent lamps of different operating system platforms on a preset network port, the preset network port being a general port supporting cross-platform data transmission, and the access request data being continuously transmitted in the form of a data stream.

[0019] The control APP system continuously listens to a preset network port. The preset port is a general port selected and can support data transmission between different operating system platforms and will not limit data reception due to platform differences.

[0020] When the intelligent lamp is ready to access the system, it can continuously send related data containing access requests to the preset port in the form of a data stream. The transmission mode of the above data stream ensures that data can be continuously received by the system, and the data sent by the intelligent lamp based on any operating system can be successfully transmitted into the system through the port.

[0021] Step S112: performing data frame analysis processing on the access request data, identifying the frame header identification and frame tail delimiter of each data frame, extracting a complete access request unit from each data frame, and a plurality of the access request units forming a set of access requests of cross-platform intelligent lamps.

[0022] After the access request data enters the system in the form of data stream, data frame analysis needs to be performed. Because the data stream contains the requests of multiple smart lamps, each lamp's request must be distinguished through analysis.

[0023] In the analysis process, the first task is to identify the frame header identifier and frame tail delimiter of each data frame. The frame header identifier is a marker at the beginning of each data frame, and the frame tail delimiter is a marker at the end of the data frame. Through these two identifiers, the continuous data stream can be divided into independent data frames. Each data frame corresponds to an access request of a smart lamp, from which a complete access request unit can be extracted. Multiple access request units described above are combined to form an access request set of cross-platform smart lamps.

[0024] Step S1121: Perform byte stream segmentation processing on the access request data, divide the continuous data stream into multiple data segments according to a preset byte length, and each data segment contains part of the access request information.

[0025] The data stream of the access request data can be long, and directly processing the entire data stream will increase the processing difficulty of the system. Therefore, byte stream segmentation processing needs to be performed first.

[0026] According to the preset byte length, the continuous data stream is divided into multiple data segments. The length of each data segment is determined according to the processing capacity of the system and the actual situation of data transmission, so as to ensure that each data segment contains part of the access request information. In this way, the long data stream is divided into shorter data segments, which facilitates subsequent detailed processing of each data segment.

[0027] Step S1122: Scan the byte content in each data segment, identify the preset frame header identifier byte sequence, and the frame header identifier byte sequence is a specific byte combination at the start position of each data frame.

[0028] After completing the byte stream segmentation, the byte content of each data segment is scanned one by one. The goal of scanning is to find the preset frame header identifier byte sequence, which is composed of a specific byte combination and is specially used to mark the start position of the data frame.

[0029] In the scanning process, the bytes in the data segment are compared with the preset frame header identifier byte sequence. When it is found that the byte combination at a certain position is completely consistent with the frame header identifier byte sequence, it is determined that the position is the start point of a data frame.

[0030] Step S1123: After identifying the frame header identifier byte sequence, continue to scan the data segment content backward to find the preset frame tail delimiter byte sequence, and the frame tail delimiter byte sequence is a specific byte combination at the end position of each data frame.

[0031] After the frame header identification byte sequence is found, the content of the current data segment is scanned from the position after the identification. This time, the scanning is to find a preset frame tail delimiter byte sequence, which is also composed of specific bytes and is used to mark the end position of the data frame.

[0032] If a complete frame tail delimiter byte sequence is not found in the current data segment, the scanned part of the data is temporarily stored, and the search continues in the next data segment until a complete frame tail delimiter is found.

[0033] Step S1124: Determine the byte range from the start position of the frame header identification byte sequence to the end position of the frame tail delimiter byte sequence. The content in the byte range is a complete data frame.

[0034] When the start position of the frame header identification and the end position of the frame tail delimiter are found, the byte range between the two positions can be determined. All byte contents in the byte range together constitute a complete data frame.

[0035] After the byte range of the data frame is determined, each access request data of the intelligent lamp can be accurately divided independently, avoiding mixing of the contents between different data frames.

[0036] Step S1125: Extract the access request related byte content from each complete data frame, remove the bytes corresponding to the frame header identification and the frame tail delimiter, obtain the access request unit, and collect all access request units to form the access request set of the cross-platform intelligent lamp.

[0037] For each complete data frame, the byte content related to the access request needs to be extracted. Since the frame header identification and the frame tail delimiter byte in the data frame are only used to mark the boundary of the frame, and are not the actual content of the access request, these bytes need to be removed.

[0038] After removing the irrelevant bytes, the access request unit is obtained. Collecting and summarizing all extracted access request units forms the access request set of the cross-platform intelligent lamp.

[0039] Step S113: Perform field splitting processing on each access request unit to separate the device identification information field, the platform type information field, and the control capability description information field. The device identification information field contains the unique hardware code of the lamp, the platform type information field contains the operating system platform name, and the control capability description information field contains the adjustable lamp state type.

[0040] After obtaining the access request unit, field splitting needs to be performed on each unit. Each access request unit contains various information, and different types of information are separated through field splitting.

[0041] After splitting, device identification information field, platform type information field and control capability description information field are obtained. The device identification information field stores the unique hardware code of the lamp, which is unique in all lamps. The platform type information field clearly records the name of the operating system platform, such as Android, iOS, Linux, etc. The control capability description information field lists the state types that the lamp can adjust, such as brightness, color temperature, color, etc.

[0042] Step S114: verifying the uniqueness of the device identification information field, comparing the stored historical device identification information library, if the device identification information field does not exist in the historical device identification information library, it is marked as a new access device identification.

[0043] In order to ensure the uniqueness of each device identification, the device identification information field needs to be verified. The device identification information in the access request unit is compared with the historical device identification information library stored in the system.

[0044] If the device identification information does not exist in the historical device identification information library, it means that it is a new smart lamp access request, which is marked as a new access device identification. If the device identification information already exists, it means that the lamp has accessed the system before.

[0045] Step S115: integrating all marked access request units, sorting according to the platform type information field, forming a classified cross-platform smart lamp access request set, each classification unit in the classified cross-platform smart lamp access request set corresponds to one operating system platform.

[0046] Integrate all the marked access request units. During the integration process, sort these access request units according to the platform type information field.

[0047] For example, all access request units belonging to the Android platform are classified into one category, those belonging to the iOS platform are classified into another category, and those belonging to the Linux platform are classified into another category. In this way, a classified cross-platform smart lamp access request set is formed, each classification unit corresponds to one operating system platform, which is convenient for subsequent access adaptation processing for different platforms.

[0048] Step S120: based on the MQTT protocol, the access request set of the cross-platform smart lamp is processed for access adaptation, according to the platform type information, the corresponding MQTT message format rule is matched, and the cross-platform access adaptation result is obtained.

[0049] After obtaining the classified access request set, access adaptation processing is performed on the requests based on the MQTT protocol. The MQTT message format rules followed by smart lamps of different operating system platforms may differ when communicating with the system.

[0050] Therefore, the corresponding MQTT message format rule needs to be matched according to the platform type information in each access request unit. Through the above adaptation processing, a cross-platform access adaptation result is obtained, ensuring that the system can effectively interact with smart lamps of different platforms.

[0051] Step S121: Extract the platform type information field of each access request unit from the access request set of the cross-platform smart lamp, establish a mapping relationship table of platform type and MQTT message format rule, and the mapping relationship table pre-stores the MQTT message header structure, field length limit and encoding format corresponding to different operating system platforms.

[0052] From the access request set of the cross-platform smart lamp, the platform type information field of each access request unit is extracted. According to these platform type information, a mapping relationship table of platform type and MQTT message format rule is established.

[0053] The mapping relationship table is pre-constructed, which stores the MQTT message header structure, field length limit and encoding format corresponding to different operating system platforms. For example, the MQTT message header structure corresponding to the Android platform may contain a specific field order, the field length has a certain limit range, and the encoding format adopts a specific way; the iOS platform may have different header structure, length limit and encoding format.

[0054] Step S122: According to the mapping relationship table, match the corresponding MQTT message format rule for the platform type information field of each access request unit, and generate a format adaptation rule document exclusive to each access request unit.

[0055] According to the established mapping relationship table, for the platform type information field of each access request unit, find the corresponding MQTT message format rule.

[0056] According to the matched format rule, generate a format adaptation rule document exclusive to each access request unit. The format adaptation rule document specifies in detail the format requirements of the messages when the smart lamp corresponding to the access request unit communicates with the system through MQTT, including how to build the header structure, how to limit the field length, and what encoding format to use, etc.

[0057] Step S123: Syntax checking processing is performed on the format adaptation rule document to check the field order of the MQTT message header structure, the numerical range of the field length limit, and the compatibility of the encoding format. If there is a syntax error, an error prompt is returned and the MQTT message format rule is matched again for the access request unit.

[0058] After the format adaptation rule document is generated, syntax checking processing needs to be performed. The checking content mainly includes whether the field order of the MQTT message header structure is correct, whether the numerical range of the field length limit is within a reasonable interval, and whether the encoding format is compatible with the corresponding platform.

[0059] If a syntax error is found in the checking process, such as reversed field order, field length exceeding the limit range, or incompatible encoding format, an error prompt is returned, and the MQTT message format rule is matched again for the access request unit from the mapping relationship table, and the format adaptation rule document is regenerated.

[0060] Step S1231: The field order description of the MQTT message header structure in the format adaptation rule document is extracted, compared with the header field order in the MQTT protocol standard, and it is judged whether there is a reversed field order or a missing field.

[0061] The field order description of the MQTT message header structure is extracted from the format adaptation rule document. These descriptions are compared in detail with the header field order specified in the MQTT protocol standard.

[0062] Each field is checked one by one to see if the position is correct, if there is a reversed field order, and if there is a missing field. If there are these problems, it means that there is a syntax error in the field order.

[0063] Step S1232: The length limit value corresponding to each header field in the format adaptation rule document is checked to verify whether the length limit value is within the valid range specified by the MQTT protocol. If the length limit value exceeds the valid range, it is marked as a length error.

[0064] The length limit value corresponding to each header field in the format adaptation rule document is checked. These values are compared with the valid range specified by the MQTT protocol to verify whether they are within a reasonable interval.

[0065] If the length limit value of a certain header field exceeds the valid range specified by the MQTT protocol, the problem is marked as a length error.

[0066] Step S1233: Analyze the encoding format specified in the format adaptation rule document, test the compatibility of the encoding format with the commonly used encoding format of the cross-platform intelligent lamp, and determine whether the converted data has loss or garbled code by simulating the conversion process between different encoding formats.

[0067] The encoding format specified in the format adaptation rule document is analyzed. In order to verify its compatibility, a simulation conversion test is performed to convert data using the encoding format and the commonly used encoding format of the cross-platform intelligent lamp.

[0068] During the conversion process, it is carefully observed whether the converted data has information loss or garbled code. If these conditions exist, it means that the encoding format compatibility has problems.

[0069] Step S1234: Count the number of field order errors, length errors, and encoding format compatibility problems, and determine that the format adaptation rule document has syntax errors if any of the errors exist.

[0070] The number of field order errors, length errors, and encoding format compatibility problems found in the previous step is counted. As long as any of the errors exist, regardless of the number, it is determined that the format adaptation rule document has syntax errors.

[0071] Step S1235: Generate error prompt information containing error type and error location, feed the error prompt information back to the MQTT message format rule matching module, trigger the re-matching process, and select the MQTT message format rule corresponding to the platform type information from the mapping relationship table to generate a new format adaptation rule document.

[0072] When it is determined that the format adaptation rule document has syntax errors, error prompt information is generated. The error prompt information explicitly contains the type of error, such as field order error, length error, encoding format compatibility problem, etc., and the specific location of the error in the document.

[0073] The error prompt information is fed back to the MQTT message format rule matching module. After receiving the feedback, the MQTT message format rule matching module triggers the re-matching process. The corresponding MQTT message format rule of the platform type information is selected from the mapping relationship table, and a new format adaptation rule document is generated based on the newly selected rule.

[0074] Step S124: Bind the format adaptation rule document that passes the verification with the device identification information field of the corresponding access request unit to generate a binding relationship pair containing device identification-format rule.

[0075] For the format adaptation rule document that passes the syntax check, bind it with the device identification information field of the corresponding access request unit.

[0076] After binding, a binding relationship pair containing device identification and format rule is formed, so that the system can quickly find the corresponding format rule according to the device identification when communicating with the smart lamp in the future, ensuring the accuracy of message interaction.

[0077] Step S125: Collect all the binding relationship pairs, combine the control capability description information in the access request set of the cross-platform smart lamp, and generate a cross-platform access adaptation result containing device adaptation status, format rule details, and control capability matching result.

[0078] Collect all the generated binding relationship pairs in the system, and then combine these binding relationship pairs with the control capability description information in the access request set of the cross-platform smart lamp.

[0079] Through comprehensive processing, a cross-platform access adaptation result is generated. The cross-platform access adaptation result contains the adaptation status of each device, i.e., whether the adaptation is successfully completed; the format rule details, i.e., the specific content of the MQTT message format rule followed by the device; and the control capability matching result, i.e., the matching situation of the control capability of the device and the control capability supported by the system.

[0080] Step S130: According to the cross-platform access adaptation result and the control capability description information, generate a unified control instruction template applicable to all access smart lamps, which contains lamp state adjustment dimensions and corresponding adjustment instruction fields.

[0081] Based on the cross-platform access adaptation result and the control capability description information, a unified control instruction template applicable to all access smart lamps needs to be generated. The unified control instruction template is the standard format of the system sending control instructions to smart lamps.

[0082] The template contains lamp state adjustment dimensions such as brightness, color temperature, color, etc., and the adjustment instruction fields corresponding to each adjustment dimension, ensuring that smart lamps of different platforms can understand and execute the control instructions sent by the system.

[0083] Step S131: Analyze the control capability matching result in the cross-platform access adaptation result, and extract the lamp state adjustment dimensions common to all access smart lamps, which are the state adjustment types supported by all access smart lamps.

[0084] The control capability matching result in the cross-platform access adaptation result is analyzed. In the analysis process, the control capabilities possessed by all access smart lamps, i.e., the common lamp state adjustment dimensions, are found out.

[0085] For example, if all smart luminaires support brightness adjustment and color temperature adjustment, then brightness and color temperature are common luminaire state adjustment dimensions. These adjustment dimensions are the basis for generating a unified control instruction template, because only adjustment types that are supported by all luminaires can be included in the unified template.

[0086] Step S132: Attribute definition processing is performed on each of the luminaire state adjustment dimensions to determine an adjustment range description, a data type identifier, and an instruction trigger condition for each adjustment dimension. The adjustment range description is an explanation of the state interval that can be adjusted for the luminaire state adjustment dimension. The data type identifier is the data format type of the adjustment instruction for the luminaire state adjustment dimension. The instruction trigger condition is the prerequisite for triggering adjustment of the luminaire state adjustment dimension.

[0087] Attribute definition processing is performed for each common luminaire state adjustment dimension. An adjustment range description is determined for each adjustment dimension, which details the state interval that can be adjusted for the dimension. For example, the brightness adjustment range can be an interval from the darkest to the brightest.

[0088] A data type identifier is determined, which is the data format type of the adjustment instruction corresponding to the adjustment dimension, such as integer type, floating point type, etc. At the same time, the instruction trigger condition is also determined, which is the prerequisite for triggering adjustment of the adjustment dimension, such as user operation on the APP, timing task triggering, etc.

[0089] Step S133: Based on the attribute definition results of all the luminaire state adjustment dimensions, a unified instruction structure framework is designed, which includes an instruction identifier segment, an adjustment dimension segment, a parameter configuration segment, and a verification segment. The instruction identifier segment is used to distinguish different types of control instructions. The adjustment dimension segment is used to specify a specific luminaire state adjustment dimension. The parameter configuration segment is used to fill in the specific adjustment parameters under the luminaire state adjustment dimension. The verification segment is used to verify the integrity of the instruction.

[0090] According to the attribute definition results of all luminaire state adjustment dimensions, a unified instruction structure framework is designed. The instruction structure framework includes multiple parts. The instruction identifier segment is used to distinguish different types of control instructions, such as brightness adjustment instructions, color temperature adjustment instructions, etc.

[0091] The adjustment dimension segment specifies a specific luminaire state adjustment dimension, i.e., which adjustment dimension the current instruction is for. The parameter configuration segment is used to fill in the specific adjustment parameters under the adjustment dimension, such as the specific numerical value of brightness adjustment. The verification segment is used to verify whether the instruction is complete during transmission, whether there is data loss or error.

[0092] Step S134: Embedding the adjustment instruction field corresponding to each lamp state adjustment dimension into the corresponding position of the instruction structure framework. The adjustment instruction field contains the adjustment dimension name, parameter input position, and verification rule. The parameter input position is the parameter filling area of the lamp state adjustment dimension in the parameter configuration section. The verification rule is the rule for verifying whether the parameters of the lamp state adjustment dimension meet the requirements.

[0093] Each lamp state adjustment dimension has its corresponding adjustment instruction field, which needs to be accurately embedded into the corresponding position of the instruction structure framework. For example, the adjustment instruction field of the brightness adjustment dimension should be embedded into the framework position related to brightness adjustment, and the adjustment instruction field of the color temperature adjustment dimension should be embedded into the framework position corresponding to color temperature adjustment.

[0094] The adjustment dimension name in the adjustment instruction field clearly identifies the adjustment dimension to which the field belongs, such as "brightness adjustment field" and "color temperature adjustment field". The parameter input position indicates the area in the parameter configuration section specifically used for filling in the parameters of the adjustment dimension, ensuring the accuracy and standardization of parameter filling. The verification rule specifies the standard for verifying whether the parameters of the adjustment dimension meet the requirements, such as whether the parameters are within the adjustment range and whether the data format is correct.

[0095] Step S135: After embedding the adjustment instruction field, the instruction structure framework is subjected to compatibility testing. The simulation process of the intelligent lamp parsing the instruction structure framework under different operating system platforms is simulated. If all simulated parsing processes can normally extract the adjustment dimensions and parameters, it is determined that the instruction structure framework is a unified control instruction template applicable to all connected intelligent lamps.

[0096] After embedding the adjustment instruction field, the instruction structure framework needs to be subjected to compatibility testing. The purpose of testing is to ensure that the framework can be correctly parsed by intelligent lamps with different operating system platforms.

[0097] By building a simulation environment, the parsing process of the instruction structure framework by intelligent lamps with different platforms is simulated. During the simulation process, it is observed whether the intelligent lamp can accurately extract the adjustment dimensions and corresponding parameters. If all simulated parsing processes can normally extract, it indicates that the instruction structure framework has good compatibility and can be determined as a unified control instruction template applicable to all connected intelligent lamps.

[0098] Step S1351: Building a simulation environment for intelligent lamps with different operating system platforms. Each simulation environment contains the operating system kernel, lamp control driver, and parsing module corresponding to the platform. The parsing module is used to parse the control instruction framework.

[0099] When building the simulation environment, a corresponding intelligent lamp simulation environment is built for each operating system platform. Each simulation environment contains the operating system kernel of the platform to simulate the real operating system running environment; it is equipped with the corresponding lamp control driver to simulate the control function of the lamp; and it is provided with an analysis module specially used for analyzing the control instruction framework.

[0100] For example, the Android platform simulation environment contains the Android operating system kernel, the Android lamp control driver and the Android analysis module; the iOS platform simulation environment contains the iOS operating system kernel, the iOS lamp control driver and the iOS analysis module, to ensure that the simulation environment can truly reflect the running state of the intelligent lamp of different platforms.

[0101] Step S1352: The instruction structure framework with the embedded adjustment instruction field is converted into simulation control instruction data, which is sent to the corresponding simulation environment according to the communication protocol format of different platforms.

[0102] The instruction structure framework with the embedded adjustment instruction field is converted into simulation control instruction data. These data need to be processed according to the communication protocol format of different operating system platforms, and then sent to the corresponding simulation environment.

[0103] For example, for the Android platform simulation environment, the simulation control instruction data needs to be packaged according to the communication protocol format of the Android platform before being sent; for the iOS platform simulation environment, the data needs to be processed and sent according to the communication protocol format of the iOS platform, to ensure that the data can be correctly received by the simulation environment.

[0104] Step S1353: Start the analysis module in each simulation environment, monitor the analysis process of the analysis module on the simulation control instruction data, and record the adjustment dimension name, parameter value and verification result extracted in the analysis process.

[0105] Start the analysis module in each simulation environment to analyze the received simulation control instruction data. In the analysis process, the running state of the analysis module is monitored in real time.

[0106] The adjustment dimension name, parameter value and verification result extracted in the analysis process are recorded in detail. These records will be important basis for judging whether the analysis is normal. Through the records, the processing of the analysis module on the instruction structure framework can be clearly understood.

[0107] Step S1354: Compare the adjustment dimension name and parameter value extracted in the analysis with the preset adjustment dimension name and parameter configuration requirement in the instruction structure framework, and judge whether they are consistent. If they are consistent, it is determined that the analysis is normal, and if they are not consistent, it is marked as abnormal.

[0108] The extracted adjustment dimension name and parameter value are compared with the preset content in the instruction structure framework. Whether the adjustment dimension name is the same and whether the parameter value meets the parameter configuration requirements, such as whether it is within the adjustment range, whether the data format is matched, and the like, are compared.

[0109] If they are consistent, it means that the parsing process is normal; if there are differences, such as incorrect adjustment dimension name or parameter value out of range, it is marked as a parsing exception.

[0110] Step S1355: The parsing results of all simulation environments are counted. If all simulation environments do not have parsing exceptions and can accurately extract adjustment dimensions and parameters, it is determined that the instruction structure framework after embedding the adjustment instruction field is a unified control instruction template applicable to all access intelligent lamps; if there is at least one simulation environment that has a parsing exception, the instruction structure framework design stage is returned to, the field design of the instruction structure framework or the embedding method of the adjustment instruction field is adjusted, and the compatibility test processing is performed again.

[0111] The parsing results of all simulation environments are counted. If all simulation environments do not have parsing exceptions and can accurately extract adjustment dimensions and parameters, it is determined that the instruction structure framework can meet the parsing requirements of different platform intelligent lamps, and can be determined as a unified control instruction template.

[0112] If there is any simulation environment that has a parsing exception, the instruction structure framework design stage is returned to. The field design of the framework is checked and adjusted, or the embedding method of the adjustment instruction field is changed, and then the compatibility test processing is performed again until all simulation environments can be normally parsed.

[0113] Step S140: The unified control instruction template is converted into an MQTT format control message according to the MQTT message format rule, and the MQTT format control message includes a topic field, a payload field, and a QoS level field, and the payload field embeds the content of the unified control instruction template.

[0114] After determining the unified control instruction template, it needs to be converted into a control message format conforming to the MQTT protocol. According to the previously matched MQTT message format rule, the unified control instruction template is format-converted.

[0115] The converted MQTT format control message includes a topic field, a payload field, and a QoS level field. The topic field is used to specify the topic of the message, the payload field embeds the specific content of the unified control instruction template, and the QoS level field indicates the service quality level of message transmission to ensure reliable message transmission.

[0116] Step S141: Extract the MQTT message format rule corresponding to each access request unit in the cross-platform access adaptation result, and determine the topic field naming specification, load field encoding requirement and QoS level selection standard in each MQTT message format rule.

[0117] From the cross-platform access adaptation result, extract the MQTT message format rule corresponding to each access request unit. Analyze these rules to determine the topic field naming specification, i.e., how the topic field should be named to be recognized by the corresponding smart lamp; determine the load field encoding requirement, i.e., what encoding method should be used to process the content of the load field; and determine the QoS level selection standard, i.e., what conditions should be used to select different QoS levels.

[0118] For example, the topic field naming specification of some platforms requires the inclusion of device type and function type, the load field encoding requirement uses a specific encoding format, and the QoS level selection standard is determined according to the importance of the control instruction.

[0119] Step S142: According to the topic field naming specification, combine the lamp state adjustment dimension corresponding to the unified control instruction template to generate the topic field content of the MQTT format control message, which contains control instruction type identification and target lamp group identification. The control instruction type identification is used to indicate that the MQTT format control message is a control message, and the target lamp group identification is used to specify the smart lamp group that receives the MQTT format control message.

[0120] According to the topic field naming specification, combine the lamp state adjustment dimension corresponding to the unified control instruction template to generate the topic field content. The topic field content contains control instruction type identification to indicate that the message is a control message, distinguishing it from other types of messages.

[0121] It also contains target lamp group identification to specify which smart lamp group receives the message. For example, the target lamp group identification can be "all living room lamps" or "all bedroom lamps", ensuring that the message is accurately sent to the target lamp.

[0122] Step S143: According to the load field encoding requirement, encode the content of the unified control instruction template to convert the instruction identification segment, adjustment dimension segment, parameter configuration segment and verification segment in the instruction structure framework into binary data that meets the encoding requirement. The binary data is embedded as the content of the load field.

[0123] According to the load field encoding requirement, encode the content of the unified control instruction template. Process the instruction identification segment, adjustment dimension segment, parameter configuration segment and verification segment in the instruction structure framework respectively to convert them into binary data that meets the encoding requirement.

[0124] These binary data are combined together as the embedded content of the payload field. The encoding process ensures that the template content can exist in a form suitable for MQTT protocol transmission, facilitating the smart lamp to receive and parse.

[0125] Step S144: According to the QoS level selection standard, the corresponding QoS level is selected for the MQTT format control message in combination with the control importance degree corresponding to the unified control instruction template. The control importance degree is determined according to the influence degree of the lamp state adjustment dimension on the normal operation of the lamp.

[0126] According to the QoS level selection standard, the QoS level is selected while considering the control importance degree corresponding to the unified control instruction template. The control importance degree is determined according to the influence degree of the lamp state adjustment dimension on the normal operation of the lamp.

[0127] For example, the control instruction related to the lamp switch has a high importance degree, and a higher QoS level can be selected to ensure reliable message transmission; while some slight brightness adjustment instructions have a relatively low importance degree, and a lower QoS level can be selected.

[0128] Step S145: The generated topic field content, the encoded payload field content and the selected QoS level field are combined and packaged, and the fields are arranged according to the message frame structure specified by the MQTT protocol to form the MQTT format control message.

[0129] The generated topic field content, the encoded payload field content and the selected QoS level field are combined and packaged. The packaging process is strictly performed according to the message frame structure specified by the MQTT protocol, and the order of each field is reasonably arranged.

[0130] Through the above combination and packaging, a complete MQTT format control message is formed, which ensures that the message meets the MQTT protocol specification and can be effectively transmitted between the system and the smart lamp.

[0131] Step S1451: Obtain the message frame structure specification specified by the MQTT protocol to determine the arrangement order of the fixed header, the variable header and the payload in the message frame, wherein the fixed header includes the message type identifier and the QoS level field, the variable header includes the topic field, and the payload includes the encoded payload field content.

[0132] First, the message frame structure specification specified by the MQTT protocol is obtained to determine the composition of the message frame and the arrangement order of each part. The message frame is usually composed of a fixed header, a variable header and a payload, the fixed header is located at the front, followed by the variable header, and finally the payload.

[0133] The fixed header contains a message type identifier and a QoS level field, which indicate the message type and transmission service quality; the variable header contains a subject field, which specifies the subject of the message; and the payload contains the encoded payload field content, which is the encoded data of the unified control instruction template.

[0134] Step S1452: Embed the selected QoS level field into the corresponding position in the message frame fixed header, and set the message type identifier in the fixed header to control command type. The identifier of the control command type is a specific value used in the MQTT protocol to represent control messages.

[0135] The previously selected QoS level field is embedded into the corresponding position in the message frame's fixed header to ensure that the fixed header accurately reflects the message's transmission service quality. Simultaneously, a message type identifier is set in the fixed header, specifying it as a control command type.

[0136] The control command type identifier is a specific value defined in the MQTT protocol to represent control messages. By setting this identifier, the receiver can quickly identify the message type as a control command.

[0137] Step S1453: Fill the generated subject field content into the subject field area of ​​the variable header of the message frame, encode the subject field content in the secondary encoding method specified by the MQTT protocol, and use the encoded payload field content as the payload part of the message frame, concatenating it after the variable header. If the payload content length exceeds the maximum single frame payload length specified by the MQTT protocol, the payload content is fragmented, and each fragment contains a fragment identifier and a fragment sequence number.

[0138] The generated topic field content is filled into the topic field area of ​​the variable header of the message frame, and then the topic field content is re-encoded according to the topic field encoding method specified by the MQTT protocol to ensure that the topic field meets the protocol requirements.

[0139] The encoded payload field content is appended to the variable header as the payload portion of the message frame. If the payload content length exceeds the maximum single-frame payload length specified by the MQTT protocol, the payload content is fragmented. Each fragment contains a fragment identifier and a fragment sequence number so that the receiver can correctly reassemble the payload content.

[0140] Step S1454: Perform overall verification processing on the fixed header, variable header, and payload or fragmented payload of the combined message frame, calculate the checksum value of the message frame, and add the checksum value to the end of the message frame to form a complete MQTT format control message; if payload fragmentation is performed, calculate the checksum value for each fragmented message frame separately.

[0141] The fixed header, variable header and payload (or the fragmented payload) of the combined message frame are subjected to an overall check processing. A checksum value of the message frame is calculated by a specific algorithm, which is used to verify whether an error or data loss occurs in the transmission process of the message.

[0142] The calculated checksum value is added at the end of the message frame, thereby forming a complete MQTT format control message. If payload fragmentation is performed, the checksum value needs to be calculated for each fragmented message frame respectively and added at the end of the corresponding fragment.

[0143] Step S150: The MQTT format control message is sent to the corresponding cross-platform smart lamp, and an instruction execution feedback message returned by the cross-platform smart lamp is received, which is encapsulated according to the MQTT protocol format and contains an execution status identifier and lamp current state information.

[0144] After the generation of the MQTT format control message is completed, it is sent to the corresponding cross-platform smart lamp. After the smart lamp receives the message and executes the corresponding control instruction, an instruction execution feedback message can be returned.

[0145] The feedback message is encapsulated according to the MQTT protocol format, which contains an execution status identifier for indicating whether the control instruction is successfully executed, and lamp current state information for describing the actual state of the lamp after the execution of the instruction, such as the current brightness, color temperature, etc.

[0146] Step S151: An MQTT communication connection corresponding to each cross-platform smart lamp is established, a connection test message is sent through the MQTT communication connection to verify the stability of the connection, and if the connection is unstable, the communication connection is re-established.

[0147] Before sending the control message, an MQTT communication connection corresponding to each cross-platform smart lamp needs to be established. After the connection is established, a connection test message is sent through the connection to verify the stability of the connection.

[0148] If the connection is unstable, such as the test message fails to be sent or no response is received, the communication connection needs to be re-established to ensure that the control message can be successfully sent to the smart lamp.

[0149] Step S152: The MQTT format control message is distributed according to the corresponding MQTT communication connection, and each cross-platform smart lamp only receives the MQTT format control message matching the device identifier information of itself.

[0150] According to the device identification information of the intelligent lamp, the MQTT format control message is distributed through the corresponding MQTT communication connection. In the distribution process, the system will filter the message to ensure that each cross-platform intelligent lamp only receives the control message matching its own device identification information.

[0151] In this way, message sending errors can be avoided, and each intelligent lamp can only process control instructions for itself.

[0152] Step S153: Listen to feedback data from cross-platform intelligent lamps on each MQTT communication connection, and the feedback data is response data generated after the intelligent lamp executes the control instruction.

[0153] After sending the control message, the system will continuously listen to each MQTT communication connection and wait to receive feedback data from cross-platform intelligent lamps. These feedback data are response information generated by the intelligent lamp after executing the control instruction, which contains the relevant information of the instruction execution.

[0154] By listening to the feedback data, the system can timely understand the execution result of the control instruction.

[0155] Step S154: Perform MQTT protocol analysis processing on the feedback data, extract the execution status identifier and the current state information of the lamp from it, the execution status identifier is used to indicate whether the control instruction is executed successfully, and the current state information of the lamp is used to describe the actual state of the lamp after executing the control instruction.

[0156] After receiving the feedback data, it is parsed according to the MQTT protocol. The execution status identifier and the current state information of the lamp are extracted from the feedback data.

[0157] The execution status identifier clearly indicates whether the control instruction is executed successfully, such as "success" or "failure"; the current state information of the lamp describes the actual state of the lamp after executing the control instruction, such as brightness value, color temperature value, color parameter, etc.

[0158] Step S155: Associate the extracted execution status identifier and the current state information of the lamp with the unified control instruction template content in the MQTT format control message, and store them to form an instruction execution record, the instruction execution record contains the control instruction content, the receiving lamp identifier, the execution state and the post-execution state information.

[0159] The extracted execution status identifier and the current state information of the lamp are associated with the unified control instruction template content in the corresponding MQTT format control message. These associated information are stored to form an instruction execution record.

[0160] The instruction execution record contains the specific content of the control instruction, the lamp identification that receives the instruction, the execution status of the instruction, and the state information of the lamp after execution, etc.

[0161] In the association storage process, it is necessary to establish the mapping relationship between data to ensure that the execution status identification, the current state information of the lamp, and the content of the unified control instruction template can accurately correspond. For example, the template content of a certain brightness adjustment control instruction is associated with the "execution success" identification and the current brightness value returned after executing the instruction to form a complete instruction execution record.

[0162] The storage method adopts a structured data storage format, which splits the control instruction content into instruction type, adjustment dimension, parameter value, and other sub-items, and together with the fields of receiving lamp identification, execution status, and post-execution state information, etc. to form a data table. Each field has a clear definition and data type, such as control instruction type in string format, parameter value in numerical format, execution status in Boolean or enumeration value format, etc. to ensure the standardization and consistency of data storage.

[0163] In order to improve the efficiency of subsequent data query and analysis, an index can be established for the stored instruction execution record. The index is based on the receiving lamp identification, instruction execution time, instruction type, and other key fields to build, so that the system can quickly locate to the instruction execution record of a specific lamp, a specific time period, or a specific type. For example, through the lamp identification index, all instruction execution histories of a certain smart lamp can be quickly queried, and through the time index, the instruction execution record can be filtered by time period.

[0164] In addition, a life cycle management mechanism for data storage is also set. According to actual needs, the storage duration of the instruction execution record is set, and for the records exceeding the storage duration, they are archived or deleted according to the preset cleaning rules, avoiding the occupation of too much storage space by too large data volume, and at the same time, ensuring that important historical records can be retained for a long time for tracing.

[0165] In the data storage process, sensitive information such as device identification needs to be handled for privacy protection. Data encryption technology is used to encrypt sensitive fields stored, and the encryption algorithm selects an encryption method that meets industry standards to ensure that even if the data storage is accessed by unauthorized access, sensitive information will not be leaked. At the same time, strict access permission control is set, only authorized system modules or personnel can access the instruction execution record data to prevent data misuse.

[0166] After the generation of the instruction execution record, it can be updated to the system's log management module and state monitoring module in synchronization. The log management module uses the record for the summary and analysis of the system operation log, helping the development and maintenance personnel to understand the system's running status and discover potential problems in a timely manner. The state monitoring module updates the state display interface of the intelligent lamp in real time according to the execution state in the execution record and the current state information of the lamp, enabling the user to intuitively view the control history and current state of the lamp.

[0167] When the system needs to be troubleshooted, the technical personnel can trace the sending content of the control instruction, the execution state and the lamp response by querying the instruction execution record. For example, if a certain intelligent lamp appears abnormal adjustment, the technical personnel can view the recent instruction execution record of the lamp, compare the control instruction parameters and the state information after execution, judge whether the abnormality is caused by the error of the instruction sending, the fault of the lamp execution or other reasons, and thus quickly locate and solve the problem.

[0168] For user query requirements, a query interface based on the instruction execution record is provided. The user can input the lamp identification, time range or instruction type, etc. query conditions to obtain the corresponding instruction execution record. The query result is displayed in a clear format, including the specific content of the control instruction, the execution time, the execution state and the lamp state after execution, etc. information, enabling the user to fully understand the control history and state change of the lamp.

[0169] When the system is optimized and upgraded, the instruction execution record also plays an important role. Through the statistical analysis of a large number of instruction execution records, the use frequency of different types of control instructions, the instruction execution success rate of different platform intelligent lamps, the common adjustment parameter range, etc. information can be understood. These analysis results provide data basis for optimizing the unified control instruction template, improving the MQTT message format conversion rule, improving the system compatibility and stability, and promote the continuous improvement of the system to better meet the control requirements of the cross-platform intelligent lamp.

[0170] Figure 2 A schematic diagram of exemplary hardware and software components of the MQTT protocol-based cross-platform intelligent lamp control APP system 100 that can implement the idea of the present application is shown. For example, the processor 120 can be used in the MQTT protocol-based cross-platform intelligent lamp control APP system 100 and used to execute the functions in the present application.

[0171] The MQTT protocol-based cross-platform smart lamp control APP system 100 can be a general server or a special-purpose server, both of which can be used to implement the MQTT protocol-based cross-platform smart lamp control APP system of the present application. The present application only shows one server, but for the sake of convenience, the functions described in the present application can be implemented in a distributed manner on multiple similar platforms to balance the processing load.

[0172] For example, the MQTT protocol-based cross-platform smart lamp control APP system 100 can include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and different forms of storage media 140, such as a disk, a ROM, or a RAM, or any combination thereof. The MQTT protocol-based cross-platform smart lamp control APP system 100 can also include program instructions stored in a ROM, a RAM, or other types of non-transitory storage media, or any combination thereof, for example. The methods of the present application can be implemented according to these program instructions. The MQTT protocol-based cross-platform smart lamp control APP system 100 also includes an I / O interface 150 between the computer and other input / output devices.

[0173] For the sake of illustration, only one processor is described in the MQTT protocol-based cross-platform smart lamp control APP system 100. However, it should be noted that the MQTT protocol-based cross-platform smart lamp control APP system 100 in the present application can also include multiple processors, so the steps performed by one processor described in the present application can also be jointly performed or individually performed by multiple processors. For example, if the processor of the MQTT protocol-based cross-platform smart lamp control APP system 100 performs steps A and B, it should be understood that steps A and B can also be performed by two different processors together or individually in one processor. For example, a first processor performs step A, a second processor performs step B, or the first processor and the second processor jointly perform steps A and B.

[0174] In addition, the present application also provides a readable storage medium, wherein computer executable instructions are pre-stored in the readable storage medium, and when the processor executes the computer executable instructions, the MQTT protocol-based cross-platform smart lamp control APP system is realized.

[0175] It should be noted that, in order to simplify the description of the present application and to help understand one or more embodiments of the present application, in the foregoing description of the embodiments of the present application, various features are sometimes combined into one embodiment, figure or description thereof.

Claims

1. A cross-platform intelligent lamp control APP system based on the MQTT protocol, characterized in that, The processor includes a processor and a memory connected to the processor. The memory stores programs, instructions, or code, and the processor executes the programs, instructions, or code in the memory to perform the following steps: Receive a set of access requests from cross-platform smart lighting fixtures, wherein the set of access requests from cross-platform smart lighting fixtures includes device identification information, platform type information and control capability description information sent by smart lighting fixtures under different operating system platforms; The access request set of the cross-platform smart lighting fixtures is adapted based on the MQTT protocol. The corresponding MQTT message format rules are matched according to the platform type information to obtain the cross-platform access adaptation result. Based on the cross-platform access adaptation results and the control capability description information, a unified control instruction template applicable to all connected smart lighting fixtures is generated. The unified control instruction template includes lighting fixture status adjustment dimensions and corresponding adjustment instruction fields. The unified control instruction template is converted into an MQTT format control message according to the MQTT message format rules. The MQTT format control message includes a subject field, a load field, and a QoS level field. The load field is embedded with the content of the unified control instruction template. The MQTT format control message is sent to the corresponding cross-platform smart lamp, and the instruction execution feedback message returned by the cross-platform smart lamp is received. The instruction execution feedback message is encapsulated in the MQTT protocol format and includes an execution status identifier and the current status information of the lamp. The system monitors access request data from smart lighting fixtures on different operating system platforms on a preset network port. The preset network port is a universal port that supports cross-platform data transmission, and the access request data is continuously transmitted in the form of a data stream. The access request data is parsed to identify the frame header identifier and frame tail separator of each data frame. A complete access request unit is extracted from each data frame. Multiple access request units form an access request set for cross-platform smart lighting. Each access request unit is processed by field splitting to separate the device identification information field, platform type information field, and control capability description information field. The device identification information field contains the unique hardware code of the lamp, the platform type information field contains the operating system platform name, and the control capability description information field contains the adjustable lamp status type. Verify the uniqueness of the device identification information field by comparing it with the stored historical device identification information database. If the device identification information field does not exist in the historical device identification information database, it is marked as a newly connected device identification. All marked access request units are integrated and sorted according to the platform type information field to form a categorized cross-platform smart lighting access request set. Each category unit in the categorized cross-platform smart lighting access request set corresponds to an operating system platform. 2.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 1, characterized in that, The access request set of the cross-platform intelligent lamp is processed based on the MQTT protocol, and a cross-platform access adaptation result is obtained according to the platform type information and the matched MQTT message format rule, including: The platform type information field of each access request unit is extracted from the access request set of the cross-platform intelligent lamp, a mapping relationship table of platform type and MQTT message format rule is established, and the mapping relationship table pre-stores the MQTT message header structure, field length limit and coding format corresponding to different operating system platforms; According to the mapping relationship table, the platform type information field of each access request unit is matched with the corresponding MQTT message format rule, and a format adaptation rule document special for each access request unit is generated; The format adaptation rule document is subjected to syntax checking processing, the field order of the MQTT message header structure, the numerical range of the field length limit and the compatibility of the coding format are checked, and if there is a syntax error, an error prompt is returned and the MQTT message format rule is matched again; The format adaptation rule document that passes the verification is bound with the device identification information field of the corresponding access request unit, and a binding relationship pair containing device identification-format rule is generated; All the binding relationship pairs are collected, and the cross-platform access adaptation result containing device adaptation state, format rule details and control capability matching result is generated in combination with the control capability description information in the access request set of the cross-platform intelligent lamp. 3.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 1, characterized in that, The cross-platform access adaptation result and the control capability description information are used to generate a unified control instruction template applicable to all access intelligent lamps, including: The control capability matching result in the cross-platform access adaptation result is analyzed, and the lamp state adjustment dimension common to all access intelligent lamps is extracted, the lamp state adjustment dimension being a state adjustment type supported by all access intelligent lamps; Each lamp state adjustment dimension is subjected to attribute definition processing, the adjustment range description, data type identifier and instruction trigger condition corresponding to each adjustment dimension are determined, the adjustment range description being an interval description of the state that can be adjusted by the lamp state adjustment dimension, the data type identifier being a data format type of the adjustment instruction of the lamp state adjustment dimension, and the instruction trigger condition being a precondition for triggering the adjustment of the lamp state adjustment dimension; Based on the attribute definition results of all the lamp state adjustment dimensions, a unified instruction structure framework is designed, the instruction structure framework including an instruction identifier segment, an adjustment dimension segment, a parameter configuration segment and a verification segment, the instruction identifier segment being used to distinguish different types of control instructions, the adjustment dimension segment being used to specify a specific lamp state adjustment dimension, the parameter configuration segment being used to fill in specific adjustment parameters under the lamp state adjustment dimension, and the verification segment being used to verify the integrity of the instruction; embedding an adjusting instruction field corresponding to each of the lamp state adjusting dimensions into a corresponding position of the instruction structure framework, the adjusting instruction field including an adjusting dimension name, a parameter input position, and a verification rule, the parameter input position being a parameter filling area of the lamp state adjusting dimension in a parameter configuration segment, and the verification rule being a rule for verifying whether parameters of the lamp state adjusting dimension meet requirements; performing compatibility test processing on the instruction structure framework after the adjusting instruction field is embedded, simulating analysis processes of the intelligent lamp on the instruction structure framework under different operating system platforms, and determining that the instruction structure framework is a unified control instruction template applicable to all connected intelligent lamps if all simulated analysis processes can normally extract adjusting dimensions and parameters. 4.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 1, wherein, The converting the unified control instruction template into an MQTT format control message according to the MQTT message format rule includes: extracting an MQTT message format rule corresponding to each access request unit in the cross-platform access adaptation result, determining a topic field naming specification, a payload field encoding requirement, and a QoS level selection standard in each MQTT message format rule; generating a topic field content of the MQTT format control message according to the topic field naming specification and in combination with lamp state adjusting dimensions corresponding to the unified control instruction template, the topic field content including a control instruction type identifier and a target lamp group identifier, the control instruction type identifier being used to indicate that the MQTT format control message is a control message, and the target lamp group identifier being used to specify a group of intelligent lamps receiving the MQTT format control message; encoding the content of the unified control instruction template according to the payload field encoding requirement, converting an instruction identifier segment, an adjusting dimension segment, a parameter configuration segment, and a verification segment in the instruction structure framework into binary data meeting the encoding requirement, and taking the binary data as embedded content of the payload field; selecting a corresponding QoS level for the MQTT format control message according to the QoS level selection standard and in combination with a control importance degree corresponding to the unified control instruction template, the control importance degree being determined according to an influence degree of the lamp state adjusting dimension on normal operation of the lamp; combining and packaging the generated topic field content, the encoded payload field content, and the selected QoS level field, arranging the fields according to a message frame structure specified by the MQTT protocol, and forming the MQTT format control message. 5.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 1, wherein, The sending the MQTT format control message to corresponding cross-platform intelligent lamps and receiving an instruction execution feedback message returned by the cross-platform intelligent lamps includes: establishing an MQTT communication connection corresponding to each cross-platform intelligent lamp, sending a connection test message through the MQTT communication connection to verify stability of the connection, and reestablishing the communication connection if the connection is unstable; distributing the MQTT format control message according to the corresponding MQTT communication connection, and causing each cross-platform intelligent lamp to only receive an MQTT format control message matching device identification information of the cross-platform intelligent lamp itself. Listen to the feedback data from the cross-platform smart lamps on each MQTT communication connection, the feedback data is the response data generated after the smart lamps execute the control instruction; Perform MQTT protocol analysis processing on the feedback data, extract the execution state identifier and the current state information of the lamps, the execution state identifier is used to indicate whether the control instruction is executed successfully, and the current state information of the lamps is used to describe the actual state of the lamps after executing the control instruction; Store the extracted execution state identifier and the current state information of the lamps in association with the unified control instruction template content in the MQTT format control message to form an instruction execution record, the instruction execution record includes control instruction content, receiving lamp identifier, execution state and post-execution state information. 6.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 1, wherein, The data frame analysis processing is performed on the access request data, the frame header identifier and the frame tail delimiter of each data frame are identified, and a complete access request unit is extracted from each data frame, a plurality of the access request units constitute an access request set of the cross-platform smart lamps, including: The byte stream segmentation processing is performed on the access request data, the continuous data stream is divided into a plurality of data segments according to a preset byte length, and each data segment contains part of the access request information; Scan the byte content in each data segment to identify the preset frame header identifier byte sequence, the frame header identifier byte sequence is a specific byte combination at the starting position of each data frame; After identifying the frame header identifier byte sequence, continue to scan the data segment content backward to find the preset frame tail delimiter byte sequence, the frame tail delimiter byte sequence is a specific byte combination at the ending position of each data frame; Determine the byte range from the starting position of the frame header identifier byte sequence to the ending position of the frame tail delimiter byte sequence, and the content in the byte range is a complete data frame; Extract the byte content related to the access request from each complete data frame, remove the bytes corresponding to the frame header identifier and the frame tail delimiter, obtain the access request unit, and collect all the access request units to constitute an access request set of the cross-platform smart lamps. 7.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 2, characterized in that, The syntax checking processing is performed on the format adaptation rule document, the field order, the field length limit and the compatibility of the encoding format of the MQTT message header structure are checked, if there is a syntax error, an error prompt is returned and the MQTT message format rule is matched again, including: Extract the field order description of the MQTT message header structure in the format adaptation rule document, compare it with the header field order in the MQTT protocol standard, and judge whether there is a field order reversal or missing; Check the length limit value of each header field in the format adaptation rule document, verify whether the length limit value is within the valid range specified by the MQTT protocol, if the length limit value exceeds the valid range, mark it as a length error; Analyze the specified encoding format in the format adaptation rule document, test the compatibility of the encoding format with the commonly used encoding format of the cross-platform smart lamps, judge whether the converted data is lost or garbled by simulating the conversion process between different encoding formats; Counting the number of errors in the order of statistical fields, length and coding format compatibility, if any error exists, it is determined that the format adaptation rule document has syntax error; Generate error prompt information containing error type and error location, feed back the error prompt information to the MQTT message format rule matching module, trigger the re-matching process, select the MQTT message format rule corresponding to the platform type information from the mapping relationship table again, and generate a new format adaptation rule document. 8.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 3, characterized in that, The compatibility test process of the instruction structure framework embedded with the adjustment instruction field is simulated to analyze the process of the intelligent lamp under different operating system platforms, and if all the simulated analysis processes can normally extract the adjustment dimension and parameter, it is determined that the instruction structure framework is a unified control instruction template suitable for all connected intelligent lamps, including: Build a simulated environment for intelligent lamps of different operating system platforms, each simulated environment contains the operating system kernel, lamp control driver and analysis module of the corresponding platform, and the analysis module is used to analyze the control instruction framework; The instruction structure framework embedded with the adjustment instruction field is converted into simulated control instruction data, which is sent to the corresponding simulated environment according to the communication protocol format of different platforms; Start the analysis module in each simulated environment, monitor the analysis process of the analysis module to the simulated control instruction data, and record the adjustment dimension name, parameter value and verification result extracted in the analysis process; Compare the adjustment dimension name and parameter value extracted in the analysis with the preset adjustment dimension name and parameter configuration requirement in the instruction structure framework to determine whether they are consistent, if they are consistent, it is determined that the analysis is normal, if they are not consistent, it is marked as abnormal analysis; Statistical results of all simulated environments, if all simulated environments do not appear abnormal analysis, and can accurately extract the adjustment dimension and parameter, it is determined that the instruction structure framework embedded with the adjustment instruction field is a unified control instruction template suitable for all connected intelligent lamps, if there is at least one simulated environment that appears abnormal analysis, return to the instruction structure framework design stage, adjust the field design of the instruction structure framework or the embedding method of the adjustment instruction field, and perform compatibility test processing again. 9.The MQTT protocol-based cross-platform smart lamp control APP system according to claim 4, characterized in that, The generated topic field content, encoded load field content and selected QoS level field are combined and packaged, and each field is arranged according to the message frame structure specified by the MQTT protocol to form the MQTT format control message, including: Obtain the message frame structure specification specified by the MQTT protocol, determine the arrangement order of the fixed header, variable header and load in the message frame, the fixed header includes message type identifier and QoS level field, the variable header includes topic field, and the load includes encoded load field content; Embed the selected QoS level field in the corresponding position of the fixed header of the message frame, and set the message type identifier in the fixed header to the control instruction type, the identifier of the control instruction type is a specific value used to represent the control message in the MQTT protocol; The generated topic field content is filled into the topic field area of the message frame variable head, the topic field content is twice encoded according to the topic field encoding mode specified in the MQTT protocol, the encoded payload field content is connected after the variable head as the payload part of the message frame, if the length of the payload content exceeds the maximum length of a single frame payload specified in the MQTT protocol, the payload content is fragmented, each fragment contains a fragment identifier and a fragment sequence number; The combined message frame fixed head, variable head and payload or fragmented payload are subjected to overall check processing, the checksum value of the message frame is calculated, and the checksum value is added at the end of the message frame to form a complete MQTT format control message; if the payload is fragmented, the checksum value is calculated for each fragmented message frame.

Images