Lightweight embedded data acquisition device data transmission and counter-control method
Patent Information
- Application Number
- CN202310368041.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-04-08
- Publication Date
- 2026-10-09
- Estimated Expiration
- 2043-04-08
AI Technical Summary
[0006]有鉴于此,本发明的目的在于提出一种轻量级的嵌入式数采设备数据传输及反控方法,以解决现有通讯协议格式复杂、需要第三方实现库、难以通用的问题
[0043] The beneficial effects of this invention are: This invention uses the plain text-based HTTP protocol, the content of requests and responses is easy to understand, the programming method is independent of the operating system, it can provide a universal way to send, receive, resume and parse data, and does not require third-party implementation libraries.
Smart Images

Figure CN116545992B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a lightweight embedded data acquisition device data transmission and reverse control method. Background Technology
[0002] Embedded and IoT data acquisition devices and their onboard programs (hereinafter referred to as device-side) are an important component of IoT and Industrial Internet applications. They transmit various data collected to the host computer (or server, hereinafter referred to as server-side) in the application, and simultaneously receive control commands issued by the server-side. However, currently widely used communication protocols (such as UART, RS232, RS485, MQTT, etc.) have the following shortcomings:
[0003] 1. Each is based on its own proprietary standards, the protocols involve a lot of content, and the protocol formats are relatively complex, requiring developers on both the device and server sides to pay additional learning costs;
[0004] 2. Some programming languages do not provide native support for these protocols (e.g., Java does not natively support RS232, RS485, etc.), and third-party implementation libraries are required;
[0005] 3. The APIs of the implementation library vary significantly across different programming languages and platforms, making it difficult for developers using different programming languages and platforms to send, receive, resume, and parse data in a more universal way. Summary of the Invention
[0006] In view of this, the purpose of this invention is to propose a lightweight embedded data acquisition device data transmission and reverse control method to solve the problems of existing communication protocol formats being complex, requiring third-party implementation libraries, and being difficult to generalize.
[0007] To achieve the above objectives, this invention provides a lightweight embedded data acquisition device data transmission and reverse control method, comprising the following steps:
[0008] S1. After each data collection is completed on the device side, use the device ID, the data collection time dt, and the collected numerical values D. i The collected switch quantities are combined into a string S and an alarm status word ST. The parameter string Params is then constructed, and the checksum vc is calculated based on the Params string.
[0009] S2. Concatenate vc and Params to form the request address, and send an HTTP request Req to the server via the HTTP protocol;
[0010] S3. The server obtains the parameter string Params and the check code vc from the received HTTP request Req. It calculates the check code VC of Params using the same encryption algorithm as the device when calculating the check code vc, and checks whether VC is consistent with vc. If they are inconsistent, Code = 1 and proceeds to step S10. If they are consistent, step S4 is executed.
[0011] S4. The server obtains the device ID from the received request Req and checks whether the ID is valid in the database. If it is invalid, Code = 2 and proceeds to step S10. If they match, proceed to step S5.
[0012] S5. The server obtains the data collection time dt from the received request Req and checks it. If dt is all 0, then Code = 0 and proceeds to step S10; otherwise, step S6 is executed.
[0013] S6. The server checks whether dt is between Now-BeforeDays and Now+AfterSeconds based on the current time Now predefined parameter BeforeDays and AfterSeconds. Here, BeforeDays is used for the device to continue transmitting data collected a few days ago, and AfterSeconds is used for the device to obtain local time that is slightly higher than the server time. If not, Code=3 and go to step S10. If yes, check whether there is already a record with the same id and dt in the database. If there is, Code=3 and go to step S10. If not, execute step S7.
[0014] S7. The server obtains the string S composed of the collected switch quantities and the collected numerical values D from the received request Req. i And check if its length and format are valid. If they are invalid, set Code = 4 and go to step S10, where 1 ≤ i ≤ M. If they are valid, execute step S8.
[0015] S8. The server obtains the alarm status word ST from the received request Req and checks whether its length and format are valid. If it is invalid, Code=5 and proceeds to step S10. If it is valid, step S9 is executed.
[0016] S9. The server will store id, dt, and each D. i A new record is created by combining S and ST, inserted into the database, and Code is set to 0.
[0017] S10. The server retrieves the pre-configured working parameters of the device and the next command to be executed from the database by ID, and sends the response content R to the device to control the device.
[0018] S11. The device obtains and parses the response content R from the server to get the new working parameters, the next command to be executed and its parameters, and then proceeds to step S10 to start the next transmission and control process.
[0019] Preferably, in the parameter string Params, id is unique, and each time the device starts up, dt is all 0, and D... i The format is floating-point, where 1 ≤ i ≤ M, M is the maximum number of numerical values supported by the device, S has a length of N, and N is the maximum number of switch values supported by the device. j The values of 1 ≤ j ≤ N are all "0, 1, -", which respectively identify the j-th switch quantity as "open, closed, unknown". Each time the device starts, all values of S are "-", and the length of ST is M+N. k The values of 1≤k≤M+N are all "0~9" or "-", where "0" represents D. i or S j-M Normal, "1-9" marked Di or S i-M An error occurred: every time the device starts up, ST is set to "0".
[0020] Preferably, step S2 includes the following sub-steps:
[0021] S21. If this data contains image P m 1≤m≤Q, where Q is the maximum number of images supported by the device. Therefore, first set P... m Serialized to Base64 encoding B m and in key-value pairs, P m B m Place the request in the body of the request and send the request using the POST method;
[0022] S22. Otherwise, send a Req in GET mode.
[0023] Preferably, in step S10, the response content R is a string concatenated from Code and the following items:
[0024] Server1: The server address that the device will access next. If this is not specified, the device will continue to use the request address in step S2 next time.
[0025] Server2: Backup address for the server;
[0026] Now: Current server time;
[0027] Interval: The time interval between the next access to the server by the device;
[0028] SensorEnables: Whether each sensor on the device is enabled;
[0029] ThresholdsD: Each D i The normal threshold range for (1≤i≤M);
[0030] ThresholdsS: Each S i The normal state of (1≤i≤N);
[0031] Cmd: The next command and parameters to be executed on the device.
[0032] Preferably, in the response content R, "|" is used as the separator and "!" is used as the end character.
[0033] This manual also provides a lightweight method for reverse control of data from embedded data acquisition devices, including the following steps:
[0034] S100, Receive the HTTP request Req sent by the receiving device;
[0035] S200: Obtain the parameter string Params and checksum vc from the received HTTP request Req. Calculate the checksum VC of Params using the same encryption algorithm used by the device to calculate the checksum vc, and check if VC matches vc. If they do not match, set Code = 1 and proceed to step S23. If they match, execute step S23. The parameter string Params consists of the device ID, the data acquisition time dt, and the acquired numerical values D. i The data is composed of a string S consisting of various switch quantities collected and an alarm status word ST spliced together.
[0036] S300: Obtain the device ID from the received request Req, and check if the ID is valid in the database. If it is invalid, set Code=2 and proceed to step S400. If they match, execute step S400.
[0037] S400: Obtain the data acquisition time dt from the received request Req, and check if dt is all 0. If so, set Code = 0 and proceed to step S500; otherwise, execute step S500.
[0038] S500: Based on the current time Now, the predefined parameter BeforeDays, and the predefined parameter AfterSeconds, check whether dt is between Now-BeforeDays and Now+AfterSeconds. BeforeDays is used for the device to continue transmitting data collected a few days ago, and AfterSeconds is used for the device to obtain local time that is slightly higher than the server time. If not, set Code=3 and proceed to step S600. If yes, check whether a record with the same id and dt already exists in the database. If it exists, set Code=3 and proceed to step S600. If it does not exist, proceed to step S600.
[0039] S600. Obtain the string S composed of the collected switch quantities and the collected numerical quantities D from the received request Req. i And check if its length and format are valid. If they are invalid, set Code = 4 and proceed to step S700, where 1 ≤ i ≤ M. If they are valid, execute step S700.
[0040] S700: Obtain the alarm status word ST from the received request Req, and check whether its length and format are valid. If it is invalid, set Code=5 and proceed to step S700. If it is valid, execute step S800.
[0041] S800, id, dt, and each D i A new record is created by combining S and ST, inserted into the database, and Code is set to 0.
[0042] S900 retrieves the pre-configured working parameters and the next command to be executed from the database using the ID, and sends the response content R to the device to control the device.
[0043] The beneficial effects of this invention are: This invention uses the plain text-based HTTP protocol, the content of requests and responses is easy to understand, the programming method is independent of the operating system, it can provide a universal way to send, receive, resume and parse data, and does not require third-party implementation libraries. Attached Figure Description
[0044] To more clearly illustrate the technical solutions in this invention 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 for this invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0045] Figure 1 This is a schematic diagram of the data transmission and counter-control method according to an embodiment of the present invention; Detailed Implementation
[0046] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.
[0047] like Figure 1 As shown in the embodiments of this specification, a lightweight embedded data acquisition device transmission and reverse control method is provided, including the following steps:
[0048] Step S1: After each data acquisition is completed, the device uses the device ID, the data acquisition time dt, the acquired numerical values Di, the string S composed of the acquired switch values, and the alarm status word ST to concatenate the parameter string Params in the form of "key=value" pairs, and calculates its checksum vc based on the Params string. A detailed explanation of Params is as follows:
[0049] 1) IDs are unique, and their length and format can be customized according to business needs;
[0050] 2) The length of dt is 14, and the format is "year, month, day, hour, minute, second". Each time the device starts, dt is all "0".
[0051] 3)D i (1≤i≤M, where M is the maximum number of numerical values supported by the device, such as 8) The format is floating point;
[0052] 4) The length of S is N (N is the maximum number of switching quantities supported by the device, such as 8), S j (1≤j≤N) takes values of "0, 1, -", which respectively identify the j-th switch quantity as "open, closed, unknown". Each time the device starts, S is all "-".
[0053] 5) ST has a length of M+N, ST k (1≤k≤M+N) takes values from 0 to 9 or -. "0" indicates D. i (1≤i≤M) or S j-M (M+1≤j≤M+N) Normal, "1~9" marked D i or S j-M Anomalies (up to 9 anomaly states can be customized for each numerical value and switch quantity according to business requirements, such as ST1=1 corresponding to D1 "Low Temperature Anomaly", ST1=2 corresponding to D1 "High Temperature Anomaly", ST1=9 corresponding to D1 "Sensor Damage Anomaly", ST... M+1 =1 corresponds to S1 "disconnection exception", etc.), "-" indicates D i or S j-MThe corresponding sensor is not enabled. If ST is all "0" or "-", it indicates that this data is normal; otherwise, it indicates that at least one value or switch value in this data is abnormal. ST is all "0" each time the device starts up.
[0054] 6) Of the above items, except for D i Apart from that, all the others are mandatory options;
[0055] 7) Params are in the form of “id=G020001&dt=20221229142030&D1=-8&D4=37.5&S=011-0--0&ST=10--2----100-2--0”.
[0056] As one implementation method, the checksum can be calculated using standard encryption algorithms such as MD5 and SHA-1. If the computing performance of the device is limited, a custom hash algorithm with lower time complexity can be used.
[0057] Step S2: Concatenate `vc` and `Params` to form the final request address (in the form of "http(s): / / server default address?vc=A8E9&Params"), and send an HTTP request `Req` to the server (or host computer) using the HTTP protocol, which is built into various programming languages and platforms. Specifically:
[0058] Step S21: If this data contains image P m (1≤m≤Q, where Q is the maximum number of images supported by the device), then first set P m Serialized to Base64 encoding B m And in the form of "key-value pairs" P m B m Place the request into the request body of the request, and then send the request using the POST method. Proceed to step S3.
[0059] Otherwise, in step S22, send a request in GET mode and proceed to step S3.
[0060] Step S3: The server obtains the parameters vc and Params from the received request Req, then calculates the checksum VC of Params using the same encryption algorithm as the device, and checks whether VC matches vc.
[0061] If the result is consistent with step S31, proceed to step S4.
[0062] Otherwise, in step S32, set Code = 1 (check code mismatch) and proceed to step S10.
[0063] Step S4: The server obtains the parameter id from the received request Req and checks whether the id is valid in the database (e.g., whether it exists, is enabled, is within its service period, has been assigned to a customer, and whether the customer to which it belongs has enabled it, etc.).
[0064] If step S41 is valid, proceed to step S5;
[0065] Otherwise, in step S42, set Code = 2 (id is invalid, or define a separate status code for each specific invalid case according to the business logic) and proceed to step S10.
[0066] Step S5: The server obtains the parameter dt from the received request Req and checks:
[0067] If dt is all 0 in step S51 (first access to the server after device startup), then set Code = 0 (access successful), and proceed to step S10; otherwise, proceed to step S6.
[0068] Step S6 uses the server's current time Now and the predefined parameters BeforeDays (in days, used for retransmission of data collected several days ago on the device) and AfterSeconds (in seconds, used when the device's local time is slightly later than the server's time) as the basis to check whether dt is between Now-BeforeDays and Now+AfterSeconds:
[0069] If step S61 is yes, then check if a record with the same id and dt already exists in the database:
[0070] 1) If it does not exist, proceed to step S7;
[0071] 2) Otherwise, set Code = 3 (dt is illegal) and proceed to step S10.
[0072] Otherwise, in step S62, set Code = 3 (dt is illegal) and proceed to step S10.
[0073] Step S7: The server obtains parameters S and each D from the received request Req. i (1≤i≤M), and check if their length and format are valid:
[0074] If all steps in S71 are valid, proceed to step S8.
[0075] Step S72 Otherwise, make Code = 4 (S or D) i (Illegal), and proceed to step S10.
[0076] Step S8: The server obtains the parameter ST from the received request Req and checks whether its length and format are valid.
[0077] If step S81 is valid, proceed to step S9;
[0078] Otherwise, in step S82, set Code = 5 (ST is illegal) and proceed to step S10.
[0079] Step S9: Set id, dt, and each D i (1≤i≤M), S, and ST form a new record, which is inserted into the database, and Code = 0 (this access was successful).
[0080] Step 10: The server retrieves the pre-configured working parameters for this device and the next command to be executed from the database using the device ID, in order to control the device remotely. Specifically, this includes:
[0081] 1) Server1: The server address to be accessed by the device next. When concurrency is high, device requests are distributed to this server to achieve load balancing. If this is not specified, the device will continue to use the default server address from step S2 next time.
[0082] 2) Server2: Backup address for the server. When Server1 becomes unresponsive, the device should continue to access this address.
[0083] 3) Now: The server's current time, used by the device to calibrate its local time;
[0084] 4) Interval: The time interval (in seconds) between the next access to the server from the device.
[0085] 5) SensorEnables: Whether each sensor on the device is enabled. The length is the same as ST (M+N), and each bit is set to SE. k All , 1≤i≤M+N) are “0 or 1”. When SE k When =0 (disabled), the device will not need to collect D data in the next sampling. i (1≤i≤M) or S j-m (M+1≤j≤M+N). If D is disabled... i Then the parameter string Params concatenated by the device should not contain D. i The corresponding "key-value pair"; if S is disabled j-M Then the next S generated by the device j (1≤j≤N) should be explicitly set to "-". Similarly, when SE k When = 0, the next ST generated by the device. k (1≤k≤M+N) should be actively set to "-";
[0086] 6) ThresholdsD: Each Di The normal threshold range of (1≤i≤M), with each D separated by M commas (",", for a total of M) i The minimum and maximum values (e.g., "-2.5, 10"), separated by semicolons (";", M-1 in total) for multiple D values. i The threshold range (e.g., "-2.5, 10; 4, 8; ..."). If the device collects D next time... i If it exceeds this range, the corresponding ST should be... i Set it to the exception status code defined by that value;
[0087] 7) ThresholdsS: Each S j The normal state (1≤j≤N) has the same length as S, and each bit is "0, 1 or -", which respectively identify S. j The normal state is when it is in the "disconnected, closed, disconnected, or closed" state. If the device collects S data next time... j If this is not the normal state, then the corresponding ST should be... j+M Set it to the agreed-upon abnormal status code for this switch quantity;
[0088] 8) Cmd: The next command to be executed on the device and its parameters, separated by commas (“,”) (the number of parameters may vary depending on the command).
[0089] 9) All of the above items, except for Server1 and Server2, are required.
[0090] 10) Combine the aforementioned Code with the above items, using vertical bars ("|", a total of 6) as separators and exclamation marks ("!") as terminators to form the string R, which serves as the server's response to the device's request.
[0091] Step S11: The device obtains and parses the response content R from the server to get the new working parameters, the next command to be executed and its parameters, and then proceeds to step S1 to start the next transmission and control process.
[0092] This specification also provides a lightweight embedded data acquisition device data reverse control method, including the following steps:
[0093] S100, Receive the HTTP request Req sent by the receiving device;
[0094] S200: Obtain the parameter string Params and checksum vc from the received HTTP request Req. Calculate the checksum VC of Params using the same encryption algorithm used by the device to calculate the checksum vc, and check if VC matches vc. If they do not match, set Code = 1 and proceed to step S23. If they match, execute step S23. The parameter string Params consists of the device ID, the data acquisition time dt, and the acquired numerical values D. i The data is composed of a string S consisting of various switch quantities collected and an alarm status word ST spliced together.
[0095] S300: Obtain the device ID from the received request Req, and check if the ID is valid in the database. If it is invalid, set Code=2 and proceed to step S400. If they match, execute step S400.
[0096] S400: Obtain the data acquisition time dt from the received request Req, and check if dt is all 0. If so, set Code = 0 and proceed to step S500; otherwise, execute step S500.
[0097] S500: Based on the current time Now, the predefined parameter BeforeDays, and the predefined parameter AfterSeconds, check whether dt is between Now-BeforeDays and Now+AfterSeconds. BeforeDays is used for the device to continue transmitting data collected a few days ago, and AfterSeconds is used for the device to obtain local time that is slightly higher than the server time. If not, set Code=3 and proceed to step S600. If yes, check whether a record with the same id and dt already exists in the database. If it exists, set Code=3 and proceed to step S600. If it does not exist, proceed to step S600.
[0098] S600. Obtain the string S composed of the collected switch quantities and the collected numerical quantities D from the received request Req. i And check if its length and format are valid. If they are invalid, set Code = 4 and proceed to step S700, where 1 ≤ i ≤ M. If they are valid, execute step S700.
[0099] S700: Obtain the alarm status word ST from the received request Req, and check whether its length and format are valid. If it is invalid, set Code=5 and proceed to step S700. If it is valid, execute step S800.
[0100] S800, id, dt, and each D i A new record is created by combining S and ST, inserted into the database, and Code is set to 0.
[0101] S900 retrieves the pre-configured working parameters and the next command to be executed from the database using the ID, and sends the response content R to the device to control the device.
[0102] This invention uses the plain text-based HTTP protocol, making the request and response content easy to understand. The programming method is independent of the operating system, providing a universal way to send, receive, resume, and parse data without requiring third-party implementation libraries.
[0103] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of the invention (including the claims) is limited to these examples; within the framework of the invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of the different aspects of the invention as described above, which are not provided in the details for the sake of brevity.
[0104] This invention is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A lightweight embedded data acquisition device data transmission and reverse control method, characterized in that, Includes the following steps: S1. After each data collection is completed on the device side, use the device ID, the data collection time dt, and the collected numerical values D. i The collected switch quantities are combined into a string S and an alarm status word ST. The parameter string Params is then constructed, and the checksum vc is calculated based on the Params string. S2. Concatenate vc and Params to form the request address, and send an HTTP request Req to the server via the HTTP protocol; S3. The server obtains the parameter string Params and the check code vc from the received HTTP request Req. It calculates the check code VC of Params using the same encryption algorithm as the device when calculating the check code vc, and checks whether VC is consistent with vc. If they are inconsistent, Code = 1 and proceeds to step S10. If they are consistent, step S4 is executed. S4. The server obtains the device ID from the received request Req and checks whether the ID is valid in the database. If it is invalid, Code = 2 and proceeds to step S10. If they match, proceed to step S5. S5. The server obtains the data collection time dt from the received request Req and checks it. If dt is all 0, then Code = 0 and proceeds to step S10; otherwise, step S6 is executed. S6. The server checks whether dt is between Now-BeforeDays and Now+AfterSeconds based on the current time Now predefined parameter BeforeDays and AfterSeconds. Here, BeforeDays is used for the device to continue transmitting data collected a few days ago, and AfterSeconds is used for the device to obtain local time that is slightly higher than the server time. If not, Code=3 and go to step S10. If yes, check whether there is already a record with the same id and dt in the database. If there is, Code=3 and go to step S10. If not, execute step S7. S7. The server obtains the string S composed of the collected switch quantities and the collected numerical values D from the received request Req. i And check if its length and format are valid. If they are invalid, set Code = 4 and go to step S10, where 1 ≤ i ≤ M. If they are valid, execute step S8. S8. The server obtains the alarm status word ST from the received request Req and checks whether its length and format are valid. If it is invalid, Code=5 and proceeds to step S10. If it is valid, step S9 is executed. S9. The server will store id, dt, and each D. i A new record is created by combining S and ST, inserted into the database, and Code is set to 0. S10. The server retrieves the pre-configured working parameters of the device and the next command to be executed from the database by ID, and sends the response content R to the device to control the device. S11. The device obtains and parses the response content R from the server to get the new working parameters, the next command to be executed and its parameters, and then proceeds to step S10 to start the next transmission and control process.
2. The data transmission and reverse control method according to claim 1, characterized in that, In the parameter string Params, id is unique. Each time the device starts up, dt is set to all zeros, and D... i The format is floating-point, where 1 ≤ i ≤ M, M is the maximum number of numerical values supported by the device, S has a length of N, and N is the maximum number of switch values supported by the device. j The values of 1≤j≤N are all "0, 1, -", which respectively identify the j-th switch quantity as "open, closed, unknown". Each time the device starts, all values of S are "-", and the length of ST is M+N. k The values of 1≤k≤M+N are all "0~9" or "-", where "0" represents D. i or S j-M Normal, "1-9" marked Di or S i-M An error occurred: every time the device starts up, ST is set to "0".
3. The data transmission and reverse control method according to claim 1, characterized in that, Step S2 includes the following sub-steps: S21. If this data contains image P m 1≤m≤Q, where Q is the maximum number of images supported by the device. Therefore, first set P... m Serialized to Base64 encoding B m and in key-value pairs, P m B m Place the request in the body of the request and send the request using the POST method; S22. Otherwise, send a Req in GET mode.
4. The data transmission and reverse control method according to claim 1, characterized in that, In step S10, the response content R is composed of Code and the following items concatenated into a string: Server1: The server address that the device will access next. If this is not specified, the device will continue to use the request address in step S2 next time. Server2: Backup address for the server; Now: Current server time; Interval: The time interval between the next access to the server by the device; SensorEnables: Whether each sensor on the device is enabled; ThresholdsD: Each D i The normal threshold range for (1≤i≤M); ThresholdsS: Each S i The normal state of (1≤i≤N); Cmd: The next command and parameters to be executed on the device.
5. The data transmission and reverse control method according to claim 4, characterized in that, In the response content R, "|" is used as the separator and "!" is used as the end character.
6. A lightweight embedded data acquisition device data reverse control method, characterized in that, Includes the following steps: S100, Receive the HTTP request Req sent by the receiving device; S200: Obtain the parameter string Params and checksum vc from the received HTTP request Req. Calculate the checksum VC of Params using the same encryption algorithm used by the device to calculate the checksum vc, and check if VC matches vc. If they do not match, set Code = 1 and proceed to step S23. If they match, execute step S23. The parameter string Params consists of the device ID, the data acquisition time dt, and the acquired numerical values D. i The data is composed of a string S consisting of various switch quantities collected and an alarm status word ST spliced together. S300: Obtain the device ID from the received request Req, and check if the ID is valid in the database. If it is invalid, set Code=2 and proceed to step S400. If they match, execute step S400. S400: Obtain the data acquisition time dt from the received request Req, and check if dt is all 0. If so, set Code = 0 and proceed to step S500; otherwise, execute step S500. S500: Based on the current time Now, the predefined parameter BeforeDays, and the predefined parameter AfterSeconds, check whether dt is between Now-BeforeDays and Now+AfterSeconds. BeforeDays is used for the device to continue transmitting data collected a few days ago, and AfterSeconds is used for the device to obtain local time that is slightly higher than the server time. If not, set Code=3 and proceed to step S600. If yes, check whether a record with the same id and dt already exists in the database. If it exists, set Code=3 and proceed to step S600. If it does not exist, proceed to step S600. S600. Obtain the string S composed of the collected switch quantities and the collected numerical quantities D from the received request Req. i And check if its length and format are valid. If they are invalid, set Code = 4 and proceed to step S700, where 1 ≤ i ≤ M. If they are valid, execute step S700. S700: Obtain the alarm status word ST from the received request Req, and check whether its length and format are valid. If it is invalid, set Code=5 and proceed to step S700. If it is valid, execute step S800. S800, id, dt, and each D i A new record is created by combining S and ST, inserted into the database, and Code is set to 0. S900 retrieves the pre-configured working parameters and the next command to be executed from the database using the ID, and sends the response content R to the device to control the device.
Citation Information
Patent Citations
Http-based cache, request and response methods, and corresponding apparatuses
WO2017045538A1
Application authentication method and system based on UDP transmission
WO2019024197A1