Internet of Things central control host data communication method and system based on protocol

Abstract

The invention provides a protocol-based Internet of Things central control host data communication method and system, and is applied to the field of communication data processing. By means of data updating timestamp detection, equipment updating frequency division, local data buffering and the like, the real-time data acquisition capability of the central control host on the multi-protocol Internet of Things equipment is improved, a layered acquisition strategy is adopted, the polling period is optimized for equipment with different frequencies, unnecessary requests are reduced, and the efficiency is improved. Meanwhile, data missing caused by long-time no response of low-frequency updating equipment is avoided, data updating abnormity can be intelligently detected, a data refreshing request is triggered, the polling period is shortened, acquisition of latest data is ensured, finally, data compensation is conducted through historical data trend analysis and missing estimation value calculation, and data integrity and continuity are improved.

Description

Technical Field

[0001] The present invention relates to the field of communication data processing, and in particular to a protocol-based Internet of Things central control host data communication method and system. Background Art

[0002] In the Internet of Things (IoT) system, the central control host serves as the core data communication node, responsible for data interaction, control command issuance and status monitoring with multiple terminal devices.

[0003] The protocol-based IoT central control host data communication method mainly involves the integration and management of multiple communication protocols (such as RS485, Modbus, MQTT, BACnet, Zigbee, BLE, etc.) to achieve the interconnection and interoperability of cross-protocol devices. However, due to the large number of IoT device types and the complex network environment, it is difficult to ensure data synchronization and consistency. Summary of the invention

[0004] The present invention aims to solve the problem that IoT devices use different protocols and the data update cycle is not fixed, resulting in the central control host being unable to obtain the latest data of all devices in real time, and provides a protocol-based IoT central control host data communication method and system.

[0005] The present invention adopts the following technical means to solve the technical problem: The present invention provides a protocol-based data communication method for a central control host of an Internet of Things, comprising: Based on the IoT device preset by the central control host, collect data update parameters of the IoT device, wherein the data update parameters specifically include a data update timestamp and a data value; Determine whether the data update parameter detects a preset update anomaly, wherein the update anomaly specifically includes an unstable update cycle and no update for a long time; If yes, then the frequency devices of the IoT devices are divided according to the data update requirements of the IoT devices, and based on the frequency devices, a unified preset time base is used to calculate the data collection interval, and a local data buffer is added on the gateway end preset by the central control host, and the previous data collection value is allowed to be returned within a preset period of time, wherein the frequency devices specifically include high-frequency devices, medium-frequency devices and low-frequency devices; Determine whether the return of the previous data collection value exceeds a preset number of times; If it exceeds, a preset data refresh request is sent to the central control host. Based on the data refresh request, the preset polling cycle is shortened, the latest data is forcibly obtained, the latest data is compared with the previous data collection value, and the missing estimate of the data update demand is calculated according to the pre-recorded historical data trend, and the missing estimate is filled in the missing data.

[0006] Furthermore, the step of dividing the frequency devices of the IoT devices according to the data update requirements of the IoT devices further includes: Based on the usage requirements of the central control host, the data synchronization frequency of the frequency device is collected; Determining whether the data synchronization frequency matches the data update requirement; If not, the preset data synchronization mechanism is dynamically adjusted according to the cache hierarchical structure preset by the central control host, and the differential data detection preset by the central control host is activated according to the data synchronization mechanism, wherein the cache hierarchical structure specifically includes a local cache layer, an edge computing layer and a cloud storage layer, the data synchronization mechanism specifically includes on-demand synchronization and batch synchronization, and the differential data detection specifically synchronizes only the changed data to reduce data redundancy.

[0007] Furthermore, before the step of adding a local data buffer on the gateway end preset by the central control host and allowing the return of the last data collection value within a preset period of time, it also includes: Based on the data reporting cycle preset by the central control host, obtain the data update mode of the IoT device, wherein the data update mode specifically includes scheduled reporting, event triggering and on-demand request; Determine whether the data update mode matches the central control host; If not, a data caching strategy for the IoT device is constructed, and the effective time range of the data cache is dynamically adjusted according to the data update frequency. According to the data caching strategy, data caching is restricted to preset non-applicable devices, wherein the non-applicable devices specifically include camera video streams and transient event monitoring devices.

[0008] Furthermore, the step of sending a preset data refresh request to the central control host further includes: Based on the communication data format of the IoT device, detecting the communication mode of the IoT device, wherein the communication data format specifically includes JSON, XML, and binary stream; Determining whether the communication method needs to enable preset encrypted communication; If so, construct the corresponding data request content according to the communication address of the IoT device, and dynamically adjust the request interval of the data request content according to the data update requirement, wherein the communication address specifically includes the IP domain name, port number and authentication method, and the data request content specifically includes specifying the target device ID, setting the data time range and increasing the request priority.

[0009] Furthermore, the step of determining whether the data update parameter detects a preset update anomaly further includes: Based on the preset data update interval of the IoT device, identifying the corresponding data change rate; Determining whether the data change rate exceeds a preset change threshold; If not, the field integrity during data update is obtained, and based on the field integrity, abnormal devices with abnormal data are detected, and preset data re-collection requests are sent to the abnormal devices in batches through the central control host, wherein the field integrity specifically includes field value and field format.

[0010] Furthermore, the step of determining whether the return of the previous data collection value exceeds a preset number of times further includes: Based on the heartbeat detection preset by the central control host, identifying the communication status of the IoT device; Determining whether the communication status is offline; If not, the timeout information of the IoT device is collected, and the data packet loss rate when the data is updated is obtained according to the timeout information, and the data packet loss rate is compared with the data receiving timestamp preset by the central control host to detect the corresponding delay and lost data.

[0011] Furthermore, the step of collecting data update parameters of the IoT devices based on the IoT devices preset by the central control host further includes: Based on the operation log of the IoT device, the communication quality between the central control host and the IoT device is detected, wherein the operation log specifically includes the average online rate, the number of offline times and the offline time period, and the communication quality specifically includes network delay, packet loss rate and signal strength; Determining whether the communication quality reaches a preset quality threshold; If not, the central control host identifies the preset high packet loss device, dynamically adjusts the data reporting interval according to the communication quality, and adaptively reduces the data transmission frequency according to the data reporting interval.

[0012] The present invention also provides a protocol-based IoT central control host data communication system, comprising: A collection module, used to collect data update parameters of the IoT devices based on the IoT devices preset by the central control host, wherein the data update parameters specifically include a data update timestamp and a data value; A judging module, used to judge whether the data update parameter detects a preset update anomaly, wherein the update anomaly specifically includes an unstable update cycle and no update for a long time; An execution module, for dividing the frequency devices of the IoT devices according to the data update requirements of the IoT devices, unifying the preset time base to calculate the data collection interval based on the frequency devices, adding a local data buffer on the gateway end preset by the central control host, and allowing the return of the last data collection value within a preset period of time, wherein the frequency devices specifically include high-frequency devices, medium-frequency devices and low-frequency devices; A second judgment module is used to judge whether the return of the previous data collection value exceeds a preset number of times; The second execution module is used to send a preset data refresh request to the central control host if it exceeds the limit. Based on the data refresh request, the preset polling cycle is shortened, the latest data is forced to be obtained, the latest data is compared with the previous data collection value, and the missing estimated value of the data update demand is calculated according to the pre-recorded historical data trend, and the missing estimated value is filled into the missing data.

[0013] Furthermore, the execution module further includes: A collection unit, used for collecting the data synchronization frequency of the frequency device based on the use requirements of the central control host; A judging unit, used to judge whether the data synchronization frequency matches the data update requirement; The execution unit is used to dynamically adjust the preset data synchronization mechanism according to the cache hierarchical structure preset by the central control host, and activate the differential data detection preset by the central control host according to the data synchronization mechanism, wherein the cache hierarchical structure specifically includes a local cache layer, an edge computing layer and a cloud storage layer, the data synchronization mechanism specifically includes on-demand synchronization and batch synchronization, and the differential data detection specifically synchronizes only the changed data to reduce data redundancy.

[0014] Furthermore, it also includes: An acquisition module, configured to acquire a data update mode of the IoT device based on a data reporting cycle preset by the central control host, wherein the data update mode specifically includes timed reporting, event triggering, and on-demand request; A third judgment module is used to judge whether the data update mode matches the central control host; The third execution module is used to, if not, construct a data caching strategy for the IoT device, dynamically adjust the effective time range of the data cache according to the data update frequency, and limit data caching to preset non-applicable devices based on the data caching strategy, wherein the non-applicable devices specifically include camera video streams and transient event monitoring devices.

[0015] The present invention provides a protocol-based data communication method and system for a central control host of the Internet of Things, which has the following beneficial effects: The present invention improves the real-time data collection capability of the central control host for multi-protocol IoT devices by means of data update timestamp detection, device update frequency division and local data buffering. It adopts a layered collection strategy to optimize the polling cycle for devices with different frequencies, reduce unnecessary requests, and avoid data loss caused by long-term non-response of low-frequency update devices. It can also intelligently detect data update anomalies, trigger data refresh requests, shorten the polling cycle, and ensure the acquisition of the latest data. Finally, through historical data trend analysis, the missing estimate is calculated to compensate for the data, thereby improving data integrity and continuity. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 It is a flow chart of an embodiment of a protocol-based IoT central control host data communication method of the present invention; Figure 2 The present invention is a structural block diagram of an embodiment of the protocol-based IoT central control host data communication system of the present invention. DETAILED DESCRIPTION

[0017] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. The implementation of the objectives, functional features and advantages of the present invention will be further described in conjunction with the embodiments and with reference to the accompanying drawings.

[0018] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0019] Reference Figure 1 , is a protocol-based IoT central control host data communication method in an embodiment of the present invention, comprising: S1: Based on the IoT device preset by the central control host, collect data update parameters of the IoT device, wherein the data update parameters specifically include a data update timestamp and a data value; S2: Determine whether the data update parameter detects a preset update anomaly, wherein the update anomaly specifically includes an unstable update cycle and no update for a long time; S3: If yes, then divide the frequency devices of the IoT devices according to the data update requirements of the IoT devices, unify the preset time base to calculate the data collection interval based on the frequency devices, add a local data buffer on the gateway end preset by the central control host, and allow the return of the last data collection value within a preset period of time, wherein the frequency devices specifically include high frequency devices, medium frequency devices and low frequency devices; S4: Determine whether the return of the previous data collection value exceeds a preset number of times; S5: If it exceeds, a preset data refresh request is sent to the central control host. Based on the data refresh request, the preset polling cycle is shortened, the latest data is forcibly obtained, the latest data is compared with the previous data collection value, and the missing estimate value of the data update demand is calculated according to the pre-recorded historical data trend, and the missing estimate value is filled into the missing data.

[0020] In this embodiment, the system collects data update parameters of these IoT devices based on the IoT devices pre-set by the central control host. The data update parameters specifically include data update timestamps and data values. Then the system determines whether these data update parameters detect pre-set update anomalies. The update anomalies specifically include unstable update cycles and long periods of non-updates, so as to execute corresponding steps. For example, when the system determines that the data update parameters of the IoT device do not detect pre-set update anomalies, the system will consider that the data update cycle of the device is stable, and the data can be uploaded normally as expected, and there is no problem of long periods of non-updates or fluctuations in update frequency. The system will continue to perform the collection according to the preset collection cycle and polling method. Data acquisition does not require adjusting the collection frequency or triggering additional data refresh requests. At the same time, the current data update timestamp and data value are stored in the database or log system for subsequent analysis and anomaly detection. The update status of the device is maintained, marking that the device is currently operating normally without additional intervention, and the data update status of the device is continuously monitored to ensure that subsequent data is still updated stably to avoid sudden abnormal situations that are not discovered in time. System resources are allocated to devices with data update anomalies first, such as reducing the polling frequency of normal devices, reducing network and computing burdens, and improving overall system efficiency. For example, when the system determines that the data update parameters of the IoT device have detected a pre-set update anomaly, The system will think that the data update cycle of the device is unstable and the data may not be uploaded normally. The system will divide the frequency devices of the IoT devices according to the data update requirements of the IoT devices. The frequency devices specifically include high-frequency devices, medium-frequency devices and low-frequency devices. According to different frequency devices, a unified pre-set time base is used to calculate the data collection interval, and a local data buffer is added to the gateway end pre-set by the central control host, allowing the previous data collection value to be returned within a pre-set time period; the system divides the device frequency (high frequency, medium frequency, low frequency) and optimizes the collection strategy according to the data update requirements of the device, making data acquisition more targeted and reducing data loss or delay problems caused by unreasonable collection strategies. When local data buffer is added on the gateway side, in case of short-term data loss or update abnormality, the system can return to the last data collection value to ensure the continuity of data flow and avoid the impact of sudden update abnormalities on business logic. In addition, the data collection interval is calculated by a unified time base, which reduces invalid polling, improves the utilization of network bandwidth and computing resources, ensures that high-frequency devices get more priority data collection, and reduces the excessive polling pressure of low-frequency devices. When data update abnormality occurs, the last data collection value can be used for supplementation in a short time to avoid data loss affecting the real-time decision-making of the system and improve the reliability and stability of the system. Then the system determines whether the return of the last data collection value exceeds the preset number of times to execute the corresponding steps.For example, when the system determines that the return of the last data collection value does not exceed the preset number of times, the system will consider that the current data update anomaly is still within the range allowed by the system, and the device has not provided new data in the short term, but the last data collection value can still be accepted as temporary fill data, and no further corrective measures need to be taken immediately. The system will continue to return the last data collection value in the cache within the response cycle of the data request to ensure the integrity of the data flow and avoid affecting the system operation due to the lack of short-term data. At the same time, it will continue to detect whether the device has resumed normal data upload in the subsequent polling cycle. If new data is detected, it will be stored and updated; if it is still not updated, it will continue to enter the next round of detection, and because the data update anomaly has not reached a serious level, it is not necessary to immediately shorten the polling cycle or trigger a data refresh request to avoid increasing unnecessary system load; for example, when the system determines that the return of the last data collection value exceeds the preset number of times, the system will consider that the current data update anomaly exceeds the system allowable range, and the device has not provided new data for a long time. The system will send a pre-set data refresh request to the central control host, and based on these data refresh requests, shorten the pre-set polling cycle, force the acquisition of the latest data, and compare these latest data with the last data collection. The system compares the values, calculates the missing estimated value of the data update demand according to the pre-collected historical data trend, and fills the missing estimated value into the missing data; the system shortens the polling cycle through data refresh requests, forces the acquisition of the latest data, and ensures that data collection is no longer delayed, which effectively avoids the situation where the device does not respond or does not update data for a long time, ensures that the system data is updated more timely, and meets the real-time requirements. At the same time, by comparing the latest data with the last data collection value, the system can accurately identify the missing data and supplement it, reduce the risk of data loss or incomplete update, make the data more continuous and complete, and provide more reliable information support for subsequent decision-making. In addition, through historical data trend analysis, the system can calculate the missing estimated value of the missing data based on the pre-collected historical data, rather than simply filling the last data collection value or missing value. This intelligent estimation enhances the accuracy of the data and avoids the problem of inaccurate data that may be caused by simple filling. By timely detecting and processing update anomalies, the system can maintain stable operation in the event of equipment failure or short-term anomalies, avoiding affecting the normal operation of the entire system. This enables the system to adapt to more environmental changes and abnormal equipment behavior, and improves the fault tolerance of the system. ;

[0021] It should be noted that, according to the data update requirements of the IoT devices, the frequency devices of the IoT devices are divided, and based on the frequency devices, a unified preset time base is used to calculate the data collection interval, and a local data buffer is added on the gateway end preset by the central control host. The specific examples are as follows: Assume that a smart building uses IoT technology to monitor environmental data and deploys the following devices: Temperature and humidity sensor (high-frequency device): reports data once per second so that the HVAC (heating, ventilation and air conditioning system) can adjust the room temperature in real time; Energy consumption monitor (medium frequency device): updated every 60 seconds, providing real-time energy consumption data to optimize power management; Smart access control system (low-frequency device): data is uploaded only once when swiping a card or remotely controlled; Optimization measures: equipment frequency division, Temperature and humidity sensor → high frequency equipment; Energy consumption monitor → medium frequency equipment; Access control system → low frequency equipment; Unified time base setting (base period: 1 second); The temperature and humidity sensor collects data once a second (1 second interval); The energy consumption monitor collects data every 60 seconds (60-second interval); The access control system only collects data when an event occurs. The gateway caches data locally. When the temperature and humidity sensors fail to report data in time due to network delays, the gateway returns the data from the previous moment to prevent HVAC from misjudging temperature changes. The data from the energy consumption monitor is cached locally and uploaded to the central control host in batches regularly to reduce communication pressure. The data from the access control system is only uploaded when an event is triggered, and no caching is required. To summarize, the above examples use different collection intervals for devices with different frequencies to reduce unnecessary polling, while reducing the network usage of high-frequency devices to ensure that data of low-frequency devices will not be lost. The gateway cache prevents data loss, and even if the device is temporarily disconnected, it can return the latest available data to avoid misjudgment of abnormalities due to long-term non-update of the device, thereby improving the reliability of the IoT system. This strategy is suitable for large-scale IoT environments, such as smart buildings, industrial monitoring, smart transportation, etc., and can effectively improve system stability and data collection accuracy.

[0022] It should be supplemented that a preset data refresh request is sent to the central control host, based on the data refresh request, the preset polling cycle is shortened, the latest data is forcibly obtained, the latest data is compared with the previous data collection value, and the missing estimated value of the data update demand is calculated according to the pre-collected historical data trend, and the missing estimated value is filled into the missing data. The specific examples are as follows: Assume that in an industrial park, a smart power monitoring system is installed with multiple power sensor devices, including: Current detector: monitors the current value of each distribution line in real time and sends data to the central control host every 60 seconds; Voltage sensor: used to detect line voltage and calculate power load in combination with current data; Power meter: provides overall power consumption and is used to optimize energy consumption; The system is used to monitor the current load of high-power equipment in the park to prevent line overload and provide data support for energy-saving management; Regarding abnormal situations, during a certain period of time, due to network jitter or unstable device signals, the current detector failed to upload data for three consecutive times, resulting in the system being unable to obtain the latest current value; at this time, the system detects an abnormality and performs the following steps: The exception handling mechanism is triggered, an exception is detected and a data refresh request is sent. Since the current data has not been updated for three consecutive times (180 seconds), the system determines that the device may have a fault or communication abnormality; a data refresh request is sent to the current detector, requiring it to re-report the data; the polling cycle is shortened. Since the data has not been updated for a long time, the system temporarily shortens the polling cycle from 60 seconds to 10 seconds, speeds up the data acquisition frequency, and tries to restore the normal data flow as soon as possible; Calculate the missing value. If the device still cannot report data, the system will calculate the missing value based on the historical data trend and fill in the missing data. The calculation method is as follows: Based on time series trend prediction, select the historical data of the past hour to extract the time series change trend of the current detector; use linear regression, exponential smoothing or LSTM (long short-term memory network) methods to predict the current value at the current moment; Example: Current data for the past hour (unit: A): 10:00->55A; 10:10->56A; 10:20->58A; 10:30->59A; 10:40->60A; 10:50->62A; Use the linear regression model to calculate the estimated current at 11:00: Estimate = slope*time+intercept; Slope ≈ (62A-55A) / (10:50-10:00) ≈ 0.14 A / min; The estimated current at 11:00 is ≈62A+0.14*10≈63.4A; Based on adjacent equipment data compensation, query the adjacent current detector data in the same distribution area and use the average value or proportional relationship to infer the missing value; Example: The current detector C1 data is lost, but the adjacent devices C2 and C3 data are as follows: C2 device current: 64A; C3 device current: 66A; Since C1, C2, and C3 are in the same power supply branch and usually have similar current loads, the weighted average method can be used: C1 estimated current = (C2 + C3) / 2 = (64A + 66A) / 2 = 65A; Based on the load characteristic model, if the device load characteristics are known, the current can be calculated based on the current voltage value and the historical load curve: Example (based on Ohm's law P=VI): Historical power load trend of equipment: 10:00->3300W; 10:10->3360W; 10:20->3480W; The current voltage is 220V, so the current estimation is: Estimated power = 3500W; Estimated current = 3500W / 220V≈15.9A; Finally, fill in the missing data and determine the final estimate. If multiple methods are available, use a weighted average: Missing current = (time series estimation + adjacent equipment estimation + load characteristic estimation) / 3; That is (63.4A+65A+15.9A) / 3≈48.1A; Fill the estimated value into the database, record the estimated data, and mark it as "estimated fill" for subsequent correction. If the device resumes normal data upload, the estimated value will be overwritten with the device's real data; To sum up, in the above examples, even if an abnormality occurs in the device, reasonable missing data filling can still be generated to avoid data interruption. By shortening the polling cycle, the latest data of the device can be quickly obtained to avoid the risk of long-term no data. At the same time, multiple estimation methods are used to ensure the accuracy of the estimated values, support the stable operation of the energy consumption optimization strategy, and prevent false alarms caused by short-term data missing, thereby improving the accuracy of anomaly detection.

[0023] In this embodiment, according to the data update requirements of the IoT devices, the step S3 of dividing the frequency devices of the IoT devices further includes: S31: Based on the usage requirements of the central control host, collect the data synchronization frequency of the frequency device; S32: Determine whether the data synchronization frequency matches the data update requirement; S33: If not, dynamically adjust the preset data synchronization mechanism according to the cache hierarchical structure preset by the central control host, and activate the differential data detection preset by the central control host according to the data synchronization mechanism, wherein the cache hierarchical structure specifically includes a local cache layer, an edge computing layer and a cloud storage layer, the data synchronization mechanism specifically includes on-demand synchronization and batch synchronization, and the differential data detection specifically synchronizes only the changed data to reduce data redundancy.

[0024] In this embodiment, the system collects the data synchronization frequency of the frequency device based on the use requirements of the central control host, and then the system determines whether these data synchronization frequencies match the data update requirements to execute the corresponding steps; for example, when the system determines that the data synchronization frequency of the frequency device can match the data update requirements, the system will consider that the current data collection frequency is consistent with the system requirements, the data transmission of the IoT device is stable, and there is no need to adjust the collection strategy. The system will continue to operate according to the existing collection cycle and data synchronization mechanism to avoid unnecessary calculations and adjustments and ensure efficient use of resources. At the same time, although the synchronization frequency matches the requirements, it is still necessary to check the data integrity and accuracy. The system compares For historical trends, ensure that data fluctuations are within the normal range, avoid abnormal values ​​affecting decision-making, verify data transmission delays, prevent timing errors caused by network congestion or equipment failures, and when the data is stable, the system can further optimize the synchronization strategy, such as dynamically adjusting the fault tolerance range to adapt to possible changes in device status in the future, improve system robustness, and record data synchronization status for subsequent analysis and optimization, such as predicting future load changes and adjusting synchronization strategies in advance; for example, when the system determines that the data synchronization frequency of the frequency device cannot match the data update requirements, the system will consider that the current data collection frequency is inconsistent with the system requirements and the data transmission is unstable. The system will adjust the synchronization strategy according to the central control master. The cache hierarchical structure pre-set by the machine, which specifically includes the local cache layer, the edge computing layer and the cloud storage layer, dynamically adjusts the pre-set data synchronization mechanism, which specifically includes on-demand synchronization and batch synchronization. According to the data synchronization mechanism, the differential data detection pre-set by the central control host is activated. The differential data detection specifically synchronizes only the changed data to reduce data redundancy; the system can adaptively adjust the synchronization mode according to the actual operating status of the device by dynamically adjusting the data synchronization mechanism (on-demand synchronization and batch synchronization), ensuring that the central control host can obtain the latest key data as soon as possible, reducing the information lag caused by device asynchrony, and using the local cache layer. , edge computing layer and cloud storage layer, and reasonably allocate data of different frequencies. For example, high-frequency data is stored in the local cache layer first for real-time reading by the central control host. Medium-frequency data can be stored in the edge computing layer and pre-processed with computing power to reduce the transmission burden. Low-frequency data is stored in the cloud storage layer to ensure long-term traceability and reduce local storage pressure. By synchronizing only the changed data, the system can avoid repeated transmission of unchanged data, which helps to reduce network traffic consumption, reduce bandwidth usage, improve overall data transmission efficiency, reduce the data storage and computing burden of the central control host, improve system processing speed, make data synchronization between devices more accurate, and reduce data errors.

[0025] It should be noted that, according to the cache hierarchical structure preset by the central control host, the preset data synchronization mechanism is dynamically adjusted, and according to the data synchronization mechanism, the differential data detection preset by the central control host is activated. The specific examples are as follows: Assume that a city's smart grid system needs to monitor the load, voltage, current and other parameters of the substation. Different monitoring devices have different data update frequencies: High-frequency devices (smart meters): update once per second; Medium frequency equipment (substation sensors): updated every 10 minutes; Low-frequency equipment (grid dispatching system): updated every hour; System optimization steps, namely cache hierarchical structure application: Smart meter data is stored in the local cache layer for real-time reading by the power distribution system; Substation sensor data is stored in the edge computing layer for short-term analysis and anomaly detection; Grid dispatch data is stored in the cloud storage layer for long-term load forecasting and optimization; Dynamically adjust the data synchronization mechanism. Smart meters use an on-demand synchronization mechanism to synchronize data only when current and voltage fluctuations exceed the threshold, reducing data transmission pressure. Substation sensors use batch synchronization, sending data every 10 minutes to reduce communication consumption. The power grid dispatching system synchronizes once a day and only uploads key indicators to reduce cloud storage costs. Activate differential data detection. When voltage and current fluctuate slightly, data synchronization will not be triggered. Data will be uploaded only when the change exceeds the set threshold (such as ±5%). If the sensor data of a substation is abnormal, the system will automatically trigger on-demand synchronization, immediately upload the latest data and adjust the dispatch strategy. Use historical trends to predict missing data. If the sensor is disconnected for a short period of time, the system will calculate the estimated value based on the current curve of the past hour to fill in the data missing points and ensure the continuity of power grid monitoring. To summarize, in the above examples, the smart meter only synchronizes data when the voltage and current fluctuate violently to avoid a large amount of invalid transmission. At the same time, different devices adopt different synchronization mechanisms to ensure that key data is acquired in real time, while non-key data is processed in batches, and the system computing and storage burden is reduced: the local cache layer reduces dependence on the central control host, the edge computing layer processes data in advance, and the cloud storage layer only stores key information. Even if some devices are temporarily disconnected, the system can calculate estimates through historical trends to maintain data integrity.

[0026] In this embodiment, a local data buffer is added on the gateway end preset by the central control host, and before step S3 of allowing the previous data collection value to be returned within a preset period of time, the following is also included: S301: Based on the data reporting cycle preset by the central control host, obtain the data update mode of the IoT device, wherein the data update mode specifically includes scheduled reporting, event triggering and on-demand request; S302: Determine whether the data update mode matches the central control host; S303: If not, construct a data caching strategy for the IoT device, dynamically adjust the effective time range of the data cache according to the data update frequency, and restrict data caching to preset non-applicable devices according to the data caching strategy, wherein the non-applicable devices specifically include camera video streams and transient event monitoring devices.

[0027] In this embodiment, the system obtains the data update mode of the IoT device based on the data reporting cycle preset by the central control host. The data update mode specifically includes timed reporting, event triggering and on-demand request. Then the system determines whether the data update mode of the IoT device matches the central control host to execute the corresponding steps; for example, when the system determines that the data update mode of the IoT device can match the central control host, the system will consider that the current data reporting method of the IoT device is consistent with the preset requirements of the central control host, and the data can be transmitted according to the expected frequency and trigger mechanism. There is no problem of information lag or redundancy, and the system does not need to adjust the data collection mechanism additionally, and maintains the current timed reporting, event triggering or on-demand request mode. By comparing historical data with current data, check whether there is data loss or abnormal jump, use redundant sensors or cross-comparison algorithms to ensure data accuracy, such as detecting whether the temperature and humidity sensor data conforms to the trend of environmental changes, and optimize data storage strategies to ensure efficient archiving of historical data, avoid duplicate storage affecting storage space, reasonably configure event trigger thresholds, avoid data overload caused by false triggers, ensure that the request scheduling mechanism is reasonable, avoid bandwidth waste due to frequent queries or data lag due to long request intervals; for example, when the system determines that the data update mode of the IoT device cannot match the central control host, the system will consider that the current data reporting method of the IoT device is inconsistent with the preset requirements of the central control host, If data cannot be transmitted as expected, the system will build a data caching strategy for IoT devices, dynamically adjust the effective time range of the cache according to the data update frequency, and limit pre-set non-applicable devices from caching data based on the data caching strategy. Non-applicable devices specifically include camera video streams and transient event monitoring devices. The system uses data caching strategies to ensure that high-frequency data or short-term changing data (such as sensor transient data) are stored within a reasonable time range without affecting the overall data transmission efficiency, and restrict non-applicable devices (such as camera video streams and transient event monitoring devices) from entering the cache to prevent the high data traffic of these devices from occupying system resources and affecting the normal data transmission of other devices. At the same time, for low-frequency data updates, Devices (such as environmental sensors, temperature and humidity monitoring equipment) can extend the cache time, avoid repeated requests, and reduce bandwidth usage. For devices with high-frequency updates (such as power monitoring and industrial automation systems), the cache time can be shortened to ensure the timeliness and availability of data. The cache validity period is dynamically adjusted according to the data update frequency of the device to ensure data availability and avoid waste of storage resources. By limiting the caching of non-applicable devices (such as high-definition video streams and transient event monitoring equipment), core business data is not affected, cache overflow or data loss is prevented, and in the case of data pattern mismatch, a cache strategy is adopted so that the system can still obtain some valid data instead of directly discarding the data, thereby improving data integrity.

[0028] In this embodiment, the step S5 of sending a preset data refresh request to the central control host further includes: S51: Detecting a communication mode of the IoT device based on a communication data format of the IoT device, wherein the communication data format specifically includes JSON, XML, and binary stream; S52: Determine whether the communication mode needs to enable preset encrypted communication; S53: If so, construct the corresponding data request content according to the communication address of the IoT device, and dynamically adjust the request interval of the data request content according to the data update requirement, wherein the communication address specifically includes the IP domain name, port number and authentication method, and the data request content specifically includes specifying the target device ID, setting the data time range and increasing the request priority.

[0029] In this embodiment, the system detects the communication mode of the IoT device based on the communication data format of the IoT device, which specifically includes JSON, XML, and binary stream, and then determines whether these communication modes need to enable pre-set encrypted communication to execute the corresponding steps; for example, when the system determines that the communication mode of the IoT device does not need to enable pre-set encrypted communication, the system will consider that the communication data format and transmission protocol used by the current device do not involve sensitive data transmission in the current application scenario, or are already in a trusted secure network environment, and no additional encryption is required. The system will perform data transmission in accordance with the preset communication data format without adding additional encryption overhead, and continue to use the ordinary transmission protocol. Protocols such as HTTP or MQTT can be used to avoid performance loss caused by encryption. At the same time, since encryption is not performed, the system can reduce the computing resource overhead required for data encryption and decryption, reduce the delay in data transmission, and reduce the size of data packets in bandwidth-constrained environments (such as wireless networks or low-power devices). Improve the real-time nature of communication, and for devices with limited computing power (such as low-power sensors), it can avoid increasing the processing burden of the device due to enabling encryption, ensure its normal operation, and avoid the problem of device processing delays or increased power consumption due to the high computational complexity of the encryption algorithm; for example, when the system determines that the communication method of the IoT device needs to enable the pre-set encrypted communication, the system will consider that the communication method currently used by the device is encrypted. The data format and transmission protocol of the letter involve sensitive data transmission, which requires additional encryption. The system will construct the corresponding data request content according to the communication address of the IoT device, which includes the IP domain name, port number and authentication method. The data request content specifically includes specifying the target device ID, setting the data time range and increasing the request priority. According to the data update requirements, the request interval of the data request content is dynamically adjusted; the system can automatically enable encrypted communication for specific data streams by judging whether the communication method needs to be encrypted, avoiding the risk of data leakage, eavesdropping or tampering caused by plain text transmission. For example, when the device uses JSON or XML format and transmits data through the public network, the system can automatically enable TLS or A ES and other encryption methods ensure that data is only parsed by authorized terminals to prevent man-in-the-middle attacks. At the same time, the system builds precise data request content based on the device's communication address (IP domain name, port number, authentication method, etc.). For example, data pull requests are only sent to specified devices instead of broadcasting to all devices. This optimization strategy reduces unnecessary data traffic, reduces network bandwidth occupancy, and improves the stability of data transmission. The system also reasonably allocates data synchronization time by dynamically adjusting the request interval period of the data request content. For example, the synchronization interval is increased for low-frequency update devices (such as environmental monitoring sensors) and the synchronization interval is shortened for high real-time devices (such as video surveillance equipment), ensuring that data from different types of devices can be efficiently transmitted on demand.

[0030] In this embodiment, the step S2 of determining whether the data update parameter detects a preset update anomaly further includes: S21: Based on the preset data update interval of the IoT device, identifying the corresponding data change rate; S22: Determine whether the data change rate exceeds a preset change threshold; S23: If not, then obtain the field integrity during data update, detect abnormal devices with abnormal data based on the field integrity, and send preset data re-collection requests to the abnormal devices in batches through the central control host, wherein the field integrity specifically includes field value and field format.

[0031] In this embodiment, the system identifies the corresponding data change rate based on the data update interval preset by the IoT device, and then the system determines whether the data change rate exceeds the preset change threshold to execute the corresponding steps; for example, when the system determines that the data change rate exceeds the preset change threshold, the system will consider that the data fluctuation of the current IoT device is abnormal, and there may be equipment failure, environmental mutation or erroneous data reporting, etc. The system will screen the abnormal data and determine whether the data change is reasonable in combination with the historical data trend and the relevant data of the surrounding sensors. For example, the temperature data of the environmental sensor fluctuates violently in a short period of time, and the system will compare the data of the surrounding temperature and humidity devices to confirm whether it is a real environmental change or a sensor failure. At the same time, if the system detects possible abnormal fluctuations, it will cross-verify with adjacent devices or historical data. For example, the power consumption of a smart meter If the power consumption data suddenly increases abnormally, the system can refer to the load conditions of adjacent meters to determine whether it is a sensor error, abnormal power consumption behavior or power theft. If the data changes too quickly, the system may need to temporarily increase the data collection frequency to obtain more detailed change trends. For example, when the acceleration sensor that monitors the health of the building structure detects abnormal vibration, it will automatically increase the data collection frequency to capture more detailed vibration patterns and assist in structural safety assessment. For example, when the system determines that the data change rate does not exceed the preset change threshold, the system will consider that the data of the current IoT device is transmitted normally, and the system will obtain the field integrity when the data is updated. The field integrity specifically includes the field value and field format. Based on these field integrity, abnormal devices that may have data abnormalities are detected, and pre-set data re-collection requests are sent to abnormal devices that may have data abnormalities in batches through the central control host.By detecting field integrity (field value and field format), the system can effectively screen out missing fields, format errors or abnormal values ​​that may exist in the data packet, avoiding calculation errors or business logic anomalies caused by incomplete data or format mismatch. For example, the data field of the temperature and humidity sensor should contain information such as temperature, humidity, and timestamp. If a field is missing, the system can immediately identify and process it. At the same time, by comparing the field integrity of each device, the system can quickly identify devices that may have data anomalies, rather than blindly re-collecting data for all devices, thereby improving detection efficiency and reducing unnecessary resource consumption. For example, in an intelligent building management system, if the data format reported by the temperature sensor in some rooms is abnormal, the system can accurately lock these sensors for review, rather than affecting the normal data reporting of all devices, and send data re-collection requests to abnormal devices in batches through the central control host, rather than sending requests to each abnormal device one by one, which can greatly reduce communication overhead, optimize system bandwidth usage, and ensure efficient data transmission. For example, in large-scale IoT deployment environments (such as smart cities and industrial monitoring), the batch processing mechanism can effectively reduce server load and improve data synchronization efficiency. ;

[0032] In this embodiment, the step S4 of determining whether the return of the previous data collection value exceeds a preset number of times further includes: S41: Identify the communication status of the IoT device based on the heartbeat detection preset by the central control host; S42: Determine whether the communication status is offline; S43: If not, collect the timeout information of the IoT device, obtain the data packet loss rate when the data is updated according to the timeout information, compare the data packet loss rate with the data receiving timestamp preset by the central control host, and detect the corresponding delay and lost data.

[0033] In this embodiment, the system identifies the communication status of the IoT device based on the heartbeat detection preset by the central control host, and then the system determines whether the communication status is offline to execute the corresponding steps; for example, when the system determines that the communication status of the IoT device is offline, the system will consider that the device can no longer communicate normally with the central control host. The system will confirm that the device is indeed offline through multiple consecutive heartbeat detections (for example, no heartbeat signal is received for 3 to 5 consecutive times), rather than temporary signal fluctuations or short communication interruptions, record the device offline time, mark the device status, and avoid affecting the data processing of other online devices. At the same time, an alarm notification is generated through the central control host interface to prompt the operation and maintenance personnel to investigate the specific cause. If the device supports remote maintenance, a firmware restart command can be sent to try to restore the normal operation of the device. When the device supports self-diagnosis, the self-test function is triggered and an error code is returned to further analyze the cause of the fault, and a local cache mechanism is enabled to store key data to avoid data loss during offline. After the device is restored online, the system can execute a data compensation mechanism to batch synchronize historical data during offline to ensure data integrity; for example, when the system determines that the communication status of the IoT device is not offline, the system will consider that the device is still connected to the central control The host maintains normal communication, and the system will collect the timeout information of the IoT device. Based on this timeout information, the data packet loss rate when the data is updated is obtained, and the data packet loss rate is compared with the data reception timestamp preset by the central control host to detect the corresponding delay and lost data; by monitoring the data packet loss rate, the system can promptly detect abnormal conditions of the IoT device during data transmission, such as network congestion, signal interference or equipment failure, thereby improving the reliability of the overall system. At the same time, based on the comparison results of the data packet loss rate and the data reception timestamp, the system can dynamically adjust the data synchronization mechanism, such as increasing the number of data retransmissions, optimizing the data packaging method or enabling differential data transmission to reduce data loss and improve data synchronization efficiency. By detecting the data reception timestamp, the system can calculate the actual data transmission delay, and adjust the data processing priority according to the application scenario of the IoT device (such as real-time monitoring or batch reporting), and optimize the system's response speed. In a large-scale IoT deployment environment, this mechanism can adaptively adjust the data transmission strategy according to the communication status of different devices to ensure that the data of key devices is transmitted first, reduce unnecessary data traffic, and improve the stability and resource utilization of the entire network.

[0034] In this embodiment, based on the IoT device preset by the central control host, the step S1 of collecting the data update parameters of the IoT device also includes: S11: Based on the operation log of the IoT device, detecting the communication quality between the central control host and the IoT device, wherein the operation log specifically includes an average online rate, the number of offline times and the offline time period, and the communication quality specifically includes network delay, packet loss rate and signal strength; S12: Determine whether the communication quality reaches a preset quality threshold; S13: If not, the central control host identifies a preset high packet loss device, dynamically adjusts the data reporting interval according to the communication quality, and adaptively reduces the data transmission frequency according to the data reporting interval.

[0035] In this embodiment, the system detects the communication quality between the central control host and the IoT device based on the operation log of the IoT device, which specifically includes the average online rate, the number of offline times and the offline time period. The communication quality specifically includes network delay, packet loss rate and signal strength. Then the system determines whether the communication quality reaches a preset quality threshold to execute the corresponding steps. For example, when the system determines that the communication quality between the central control host and the IoT device can reach the preset quality threshold, the system will consider that the current communication status between the IoT device and the central control host is normal, the data transmission is stable, and the requirements of real-time data exchange can be met. When the communication quality reaches the preset threshold, the system will continue Transmit data at the normal data update frequency to ensure that device data is reported on time and is not affected by network factors, ensuring the real-time and integrity of the data. At the same time, according to the actual data update needs of the device, further optimize the frequency of data collection. For example, if the device usage scenario requires high-frequency data updates, the collection frequency can be appropriately increased, or the data transmission time window can be dynamically adjusted according to business needs to ensure efficient use of system resources. In addition, according to the good communication quality of the device, redundant operations such as data retransmission, error checking and data rollback can be reduced, thereby reducing the burden on the central control host and improving the overall system operation efficiency and response speed. For example, when the system determines that the central control host and the IoT device are in communication, the system will automatically send data to the central control host, and ... If the communication quality of the device cannot reach the preset quality threshold, the system will consider that the communication status between the current IoT device and the central control host is abnormal. The system will identify the preset high packet loss device through the central control host, and dynamically adjust the data reporting interval according to different communication qualities. According to the data reporting interval, the data transmission frequency is adaptively reduced; by dynamically adjusting the data reporting interval, the system can avoid frequent data retransmission or error checking caused by high packet loss rate or unstable communication quality, thereby reducing unnecessary bandwidth occupation and system burden. Reducing the data transmission frequency helps to reduce the pressure on the central control host and the network, especially under high load conditions, which can ensure the stability and performance of the system. It can adaptively adjust the data reporting frequency according to the communication quality and packet loss of the device, and can effectively cope with the actual communication conditions of different devices. For example, when the signal is weak or the network fluctuates greatly, the system will automatically reduce the frequency of data collection and transmission to avoid excessive data loss and system abnormalities. This allows the device to maintain connection with the central control host when the communication quality is unstable, without causing serious lag or loss of information. For devices with poor communication quality, the system can effectively reduce the risk of packet loss by reducing the data transmission frequency. A lower frequency helps avoid too frequent transmission requests, aggravating network congestion and leading to more data loss.

[0036] Reference Figure 2 , is a protocol-based IoT central control host data communication system in one embodiment of the present invention, comprising: The collection module 10 is used to collect data update parameters of the IoT devices based on the IoT devices preset by the central control host, wherein the data update parameters specifically include a data update timestamp and a data value; A judging module 20, configured to judge whether the data updating parameter detects a preset updating anomaly, wherein the updating anomaly specifically includes an unstable updating cycle and a long period of non-updating; The execution module 30 is used for dividing the frequency devices of the IoT devices according to the data update requirements of the IoT devices, unifying the preset time base to calculate the data collection interval according to the frequency devices, adding a local data buffer on the gateway end preset by the central control host, and allowing the return of the last data collection value within a preset period of time, wherein the frequency devices specifically include high-frequency devices, medium-frequency devices and low-frequency devices; The second judgment module 40 is used to judge whether the return of the previous data collection value exceeds a preset number of times; The second execution module 50 is used to send a preset data refresh request to the central control host if it exceeds the limit. Based on the data refresh request, the preset polling cycle is shortened, the latest data is forcibly obtained, the latest data is compared with the previous data collection value, and the missing estimated value of the data update demand is calculated according to the pre-recorded historical data trend, and the missing estimated value is filled into the missing data.

[0037] In this embodiment, the acquisition module 10 collects data update parameters of these IoT devices based on the IoT devices pre-set by the central control host. The data update parameters specifically include data update timestamps and data values. Then the judgment module 20 judges whether these data update parameters detect preset update anomalies. The update anomalies specifically include unstable update cycles and long periods of non-updates, so as to execute corresponding steps. For example, when the system determines that the data update parameters of the IoT device do not detect the preset update anomalies, the system will consider that the data update cycle of the device is stable, and the data can be uploaded normally as expected, and there is no problem of long-term non-updates or fluctuations in update frequency. The system will continue to update according to the preset acquisition cycle and polling method. Data is acquired in a simple manner without adjusting the acquisition frequency or triggering additional data refresh requests. At the same time, the current data update timestamp and data value are stored in the database or log system for subsequent analysis and anomaly detection. The update status of the device is maintained, marking that the device is currently operating normally without additional intervention, and the data update status of the device is continuously monitored to ensure that subsequent data is still updated stably to avoid sudden abnormal situations from being discovered in time. System resources are allocated to devices with data update anomalies first, such as reducing the polling frequency of normal devices, reducing network and computing burdens, and improving overall system efficiency. For example, when the system determines that the data update parameters of the IoT device have detected a pre-set update anomaly, the execution The row module 30 will think that the data update cycle of the device is unstable and the data may not be uploaded normally. The system will divide the frequency devices of the IoT devices according to the data update requirements of the IoT devices. The frequency devices specifically include high-frequency devices, medium-frequency devices and low-frequency devices. According to different frequency devices, a unified pre-set time base is used to calculate the data collection interval, and a local data buffer is added on the gateway end pre-set by the central control host to allow the return of the previous data collection value within a pre-set time period; the system divides the device frequency (high frequency, medium frequency, low frequency) and optimizes the collection strategy according to the data update requirements of the device, so that data acquisition is more targeted and data loss or delay caused by unreasonable collection strategies is reduced. A local data buffer is added at the gateway end. When short-term data is lost or updated abnormally, the system can return to the last data collection value to ensure the continuity of the data flow and avoid the impact of sudden update abnormalities on the business logic. The data collection interval is calculated by a unified time base, which reduces invalid polling, improves the utilization rate of network bandwidth and computing resources, ensures that high-frequency devices get more priority data collection, and reduces the excessive polling pressure of low-frequency devices. When data update abnormalities occur, the last data collection value can be used for supplementation in a short time to avoid data loss affecting the real-time decision-making of the system and improve the reliability and stability of the system. Then the second judgment module 40 judges whether the return of the last data collection value exceeds the preset number of times to execute the corresponding steps.For example, when the system determines that the return of the previous data acquisition value does not exceed the preset number of times, the system will consider that the current data update anomaly is still within the range allowed by the system, and the device has not provided new data in the short term, but the previous data acquisition value can still be accepted as temporary fill data, and no further corrective measures need to be taken immediately. The system will continue to return the previous data acquisition value in the cache within the response cycle of the data request to ensure the integrity of the data stream and avoid affecting the system operation due to the lack of short-term data. At the same time, it will continue to detect whether the device has resumed normal data upload in the subsequent polling cycle. If new data is detected, it will be stored and updated; if it is still not updated, it will continue to enter the next round of detection, and because the data update anomaly has not reached a serious level, it is not necessary to immediately shorten the polling cycle or trigger a data refresh request to avoid increasing unnecessary system load; for example, when the system determines that the return of the previous data acquisition value exceeds the preset number of times, at this time, the second execution module 50 will consider that the current data update anomaly exceeds the system allowable range, and the device has not provided new data for a long time. The system will send a pre-set data refresh request to the central control host, based on these data refresh requests, shorten the pre-set polling cycle, force the acquisition of the latest data, and compare these latest data with the previous data. According to the collected values, the missing estimated values ​​of the data update requirements are calculated according to the historical data trends collected in advance, and the missing estimated values ​​are filled into the missing data; the system shortens the polling cycle through data refresh requests, forces the acquisition of the latest data, and ensures that data collection is no longer delayed. This effectively avoids the situation where the device does not respond or does not update data for a long time, ensures that the system data is updated more timely, and meets the real-time requirements. At the same time, by comparing the latest data with the last data collection value, the system can accurately identify the missing data and supplement it, reduce the risk of data loss or incomplete update, make the data more continuous and complete, and provide more reliable information support for subsequent decision-making. In addition, through historical data trend analysis, the system can calculate the missing estimated values ​​of the missing data based on the pre-collected historical data, rather than simply filling the last data collection value or missing value. This intelligent estimation enhances the accuracy of the data and avoids the problem of inaccurate data that may be caused by simple filling. By timely detecting and processing update anomalies, the system can maintain stable operation in the event of equipment failure or short-term anomalies, avoiding affecting the normal operation of the entire system. This enables the system to adapt to more environmental changes and abnormal equipment behavior, and improves the fault tolerance of the system. ;

[0038] In this embodiment, the execution module further includes: A collection unit, used for collecting the data synchronization frequency of the frequency device based on the use requirements of the central control host; A judging unit, used to judge whether the data synchronization frequency matches the data update requirement; The execution unit is used to dynamically adjust the preset data synchronization mechanism according to the cache hierarchical structure preset by the central control host, and activate the differential data detection preset by the central control host according to the data synchronization mechanism, wherein the cache hierarchical structure specifically includes a local cache layer, an edge computing layer and a cloud storage layer, the data synchronization mechanism specifically includes on-demand synchronization and batch synchronization, and the differential data detection specifically synchronizes only the changed data to reduce data redundancy.

[0039] In this embodiment, the system collects the data synchronization frequency of the frequency device based on the use requirements of the central control host, and then the system determines whether these data synchronization frequencies match the data update requirements to execute the corresponding steps; for example, when the system determines that the data synchronization frequency of the frequency device can match the data update requirements, the system will consider that the current data collection frequency is consistent with the system requirements, the data transmission of the IoT device is stable, and there is no need to adjust the collection strategy. The system will continue to operate according to the existing collection cycle and data synchronization mechanism to avoid unnecessary calculations and adjustments and ensure efficient use of resources. At the same time, although the synchronization frequency matches the requirements, it is still necessary to check the data integrity and accuracy. The system compares For historical trends, ensure that data fluctuations are within the normal range, avoid abnormal values ​​affecting decision-making, verify data transmission delays, prevent timing errors caused by network congestion or equipment failures, and when the data is stable, the system can further optimize the synchronization strategy, such as dynamically adjusting the fault tolerance range to adapt to possible changes in device status in the future, improve system robustness, and record data synchronization status for subsequent analysis and optimization, such as predicting future load changes and adjusting synchronization strategies in advance; for example, when the system determines that the data synchronization frequency of the frequency device cannot match the data update requirements, the system will consider that the current data collection frequency is inconsistent with the system requirements and the data transmission is unstable. The system will adjust the synchronization strategy according to the central control master. The cache hierarchical structure pre-set by the machine, which specifically includes the local cache layer, the edge computing layer and the cloud storage layer, dynamically adjusts the pre-set data synchronization mechanism, which specifically includes on-demand synchronization and batch synchronization. According to the data synchronization mechanism, the differential data detection pre-set by the central control host is activated. The differential data detection specifically synchronizes only the changed data to reduce data redundancy; the system can adaptively adjust the synchronization mode according to the actual operating status of the device by dynamically adjusting the data synchronization mechanism (on-demand synchronization and batch synchronization), ensuring that the central control host can obtain the latest key data as soon as possible, reducing the information lag caused by device asynchrony, and using the local cache layer. , edge computing layer and cloud storage layer, and reasonably allocate data of different frequencies. For example, high-frequency data is stored in the local cache layer first for real-time reading by the central control host. Medium-frequency data can be stored in the edge computing layer and pre-processed with computing power to reduce the transmission burden. Low-frequency data is stored in the cloud storage layer to ensure long-term traceability and reduce local storage pressure. By synchronizing only the changed data, the system can avoid repeated transmission of unchanged data, which helps to reduce network traffic consumption, reduce bandwidth usage, improve overall data transmission efficiency, reduce the data storage and computing burden of the central control host, improve system processing speed, make data synchronization between devices more accurate, and reduce data errors.

[0040] In this embodiment, it also includes: An acquisition module, configured to acquire a data update mode of the IoT device based on a data reporting cycle preset by the central control host, wherein the data update mode specifically includes timed reporting, event triggering, and on-demand request; A third judgment module is used to judge whether the data update mode matches the central control host; The third execution module is used to, if not, construct a data caching strategy for the IoT device, dynamically adjust the effective time range of the data cache according to the data update frequency, and limit data caching to preset non-applicable devices based on the data caching strategy, wherein the non-applicable devices specifically include camera video streams and transient event monitoring devices.

[0041] In this embodiment, the system obtains the data update mode of the IoT device based on the data reporting cycle preset by the central control host. The data update mode specifically includes timed reporting, event triggering and on-demand request. Then the system determines whether the data update mode of the IoT device matches the central control host to execute the corresponding steps; for example, when the system determines that the data update mode of the IoT device can match the central control host, the system will consider that the current data reporting method of the IoT device is consistent with the preset requirements of the central control host, and the data can be transmitted according to the expected frequency and trigger mechanism. There is no problem of information lag or redundancy, and the system does not need to adjust the data collection mechanism additionally, and maintains the current timed reporting, event triggering or on-demand request mode. By comparing historical data with current data, check whether there is data loss or abnormal jump, use redundant sensors or cross-comparison algorithms to ensure data accuracy, such as detecting whether the temperature and humidity sensor data conforms to the trend of environmental changes, and optimize data storage strategies to ensure efficient archiving of historical data, avoid duplicate storage affecting storage space, reasonably configure event trigger thresholds, avoid data overload caused by false triggers, ensure that the request scheduling mechanism is reasonable, avoid bandwidth waste due to frequent queries or data lag due to long request intervals; for example, when the system determines that the data update mode of the IoT device cannot match the central control host, the system will consider that the current data reporting method of the IoT device is inconsistent with the preset requirements of the central control host, If data cannot be transmitted as expected, the system will build a data caching strategy for IoT devices, dynamically adjust the effective time range of the cache according to the data update frequency, and limit pre-set non-applicable devices from caching data based on the data caching strategy. Non-applicable devices specifically include camera video streams and transient event monitoring devices. The system uses data caching strategies to ensure that high-frequency data or short-term changing data (such as sensor transient data) are stored within a reasonable time range without affecting the overall data transmission efficiency, and restrict non-applicable devices (such as camera video streams and transient event monitoring devices) from entering the cache to prevent the high data traffic of these devices from occupying system resources and affecting the normal data transmission of other devices. At the same time, for low-frequency data updates, Devices (such as environmental sensors, temperature and humidity monitoring equipment) can extend the cache time, avoid repeated requests, and reduce bandwidth usage. For devices with high-frequency updates (such as power monitoring and industrial automation systems), the cache time can be shortened to ensure the timeliness and availability of data. The cache validity period is dynamically adjusted according to the data update frequency of the device to ensure data availability and avoid waste of storage resources. By limiting the caching of non-applicable devices (such as high-definition video streams and transient event monitoring equipment), core business data is not affected, cache overflow or data loss is prevented, and in the case of data pattern mismatch, a cache strategy is adopted so that the system can still obtain some valid data instead of directly discarding the data, thereby improving data integrity.

[0042] In this embodiment, the second execution module further includes: A detection unit, configured to detect a communication mode of the IoT device based on a communication data format of the IoT device, wherein the communication data format specifically includes JSON, XML, and a binary stream; A second judgment unit, used to judge whether the communication mode needs to enable preset encrypted communication; The second execution unit is used to, if yes, construct corresponding data request content according to the communication address of the Internet of Things device, and dynamically adjust the request interval period of the data request content according to the data update requirement, wherein the communication address specifically includes the IP domain name, port number and authentication method, and the data request content specifically includes specifying the target device ID, setting the data time range and increasing the request priority.

[0043] In this embodiment, the system detects the communication mode of the IoT device based on the communication data format of the IoT device, which specifically includes JSON, XML, and binary stream, and then determines whether these communication modes need to enable pre-set encrypted communication to execute the corresponding steps; for example, when the system determines that the communication mode of the IoT device does not need to enable pre-set encrypted communication, the system will consider that the communication data format and transmission protocol used by the current device do not involve sensitive data transmission in the current application scenario, or are already in a trusted secure network environment, and no additional encryption is required. The system will perform data transmission in accordance with the preset communication data format without adding additional encryption overhead, and continue to use the ordinary transmission protocol. Protocols such as HTTP or MQTT can be used to avoid performance loss caused by encryption. At the same time, since encryption is not performed, the system can reduce the computing resource overhead required for data encryption and decryption, reduce the delay in data transmission, and reduce the size of data packets in bandwidth-constrained environments (such as wireless networks or low-power devices). Improve the real-time nature of communication, and for devices with limited computing power (such as low-power sensors), it can avoid increasing the processing burden of the device due to enabling encryption, ensure its normal operation, and avoid the problem of device processing delays or increased power consumption due to the high computational complexity of the encryption algorithm; for example, when the system determines that the communication method of the IoT device needs to enable the pre-set encrypted communication, the system will consider that the communication method currently used by the device is encrypted. The data format and transmission protocol of the letter involve sensitive data transmission, which requires additional encryption. The system will construct the corresponding data request content according to the communication address of the IoT device, which includes the IP domain name, port number and authentication method. The data request content specifically includes specifying the target device ID, setting the data time range and increasing the request priority. According to the data update requirements, the request interval of the data request content is dynamically adjusted; the system can automatically enable encrypted communication for specific data streams by judging whether the communication method needs to be encrypted, avoiding the risk of data leakage, eavesdropping or tampering caused by plain text transmission. For example, when the device uses JSON or XML format and transmits data through the public network, the system can automatically enable TLS or A ES and other encryption methods ensure that data is only parsed by authorized terminals to prevent man-in-the-middle attacks. At the same time, the system builds precise data request content based on the device's communication address (IP domain name, port number, authentication method, etc.). For example, data pull requests are only sent to specified devices instead of broadcasting to all devices. This optimization strategy reduces unnecessary data traffic, reduces network bandwidth occupancy, and improves the stability of data transmission. The system also reasonably allocates data synchronization time by dynamically adjusting the request interval period of the data request content. For example, the synchronization interval is increased for low-frequency update devices (such as environmental monitoring sensors) and the synchronization interval is shortened for high real-time devices (such as video surveillance equipment), ensuring that data from different types of devices can be efficiently transmitted on demand.

[0044] In this embodiment, the judgment module further includes: An identification unit, configured to identify a corresponding data change rate based on a preset data update interval of the IoT device; A third judgment unit, used to judge whether the data change rate exceeds a preset change threshold; The third execution unit is used to obtain the field integrity when the data is updated if not, detect abnormal devices with abnormal data according to the field integrity, and send preset data re-collection requests to the abnormal devices in batches through the central control host, wherein the field integrity specifically includes field value and field format.

[0045] In this embodiment, the system identifies the corresponding data change rate based on the data update interval preset by the IoT device, and then the system determines whether the data change rate exceeds the preset change threshold to execute the corresponding steps; for example, when the system determines that the data change rate exceeds the preset change threshold, the system will consider that the data fluctuation of the current IoT device is abnormal, and there may be equipment failure, environmental mutation or erroneous data reporting, etc. The system will screen the abnormal data and determine whether the data change is reasonable in combination with the historical data trend and the relevant data of the surrounding sensors. For example, the temperature data of the environmental sensor fluctuates violently in a short period of time, and the system will compare the data of the surrounding temperature and humidity devices to confirm whether it is a real environmental change or a sensor failure. At the same time, if the system detects possible abnormal fluctuations, it will cross-verify with adjacent devices or historical data. For example, the power consumption of a smart meter If the power consumption data suddenly increases abnormally, the system can refer to the load conditions of adjacent meters to determine whether it is a sensor error, abnormal power consumption behavior or power theft. If the data changes too quickly, the system may need to temporarily increase the data collection frequency to obtain more detailed change trends. For example, when the acceleration sensor that monitors the health of the building structure detects abnormal vibration, it will automatically increase the data collection frequency to capture more detailed vibration patterns and assist in structural safety assessment. For example, when the system determines that the data change rate does not exceed the preset change threshold, the system will consider that the data of the current IoT device is transmitted normally, and the system will obtain the field integrity when the data is updated. The field integrity specifically includes the field value and field format. Based on these field integrity, abnormal devices that may have data abnormalities are detected, and pre-set data re-collection requests are sent to abnormal devices that may have data abnormalities in batches through the central control host.By detecting field integrity (field value and field format), the system can effectively screen out missing fields, format errors or abnormal values ​​that may exist in the data packet, avoiding calculation errors or business logic anomalies caused by incomplete data or format mismatch. For example, the data field of the temperature and humidity sensor should contain information such as temperature, humidity, and timestamp. If a field is missing, the system can immediately identify and process it. At the same time, by comparing the field integrity of each device, the system can quickly identify devices that may have data anomalies, rather than blindly re-collecting data for all devices, thereby improving detection efficiency and reducing unnecessary resource consumption. For example, in an intelligent building management system, if the data format reported by the temperature sensor in some rooms is abnormal, the system can accurately lock these sensors for review, rather than affecting the normal data reporting of all devices, and send data re-collection requests to abnormal devices in batches through the central control host, rather than sending requests to each abnormal device one by one, which can greatly reduce communication overhead, optimize system bandwidth usage, and ensure efficient data transmission. For example, in large-scale IoT deployment environments (such as smart cities and industrial monitoring), the batch processing mechanism can effectively reduce server load and improve data synchronization efficiency. ;

[0046] In this embodiment, the second determination module further includes: A second identification unit is used to identify the communication status of the Internet of Things device based on the heartbeat detection preset by the central control host; A fourth determination unit, used to determine whether the communication status is offline; The fourth execution unit is used to collect the timeout information of the Internet of Things device if not, obtain the data packet loss rate when the data is updated according to the timeout information, compare the data packet loss rate with the data receiving timestamp preset by the central control host, and detect the corresponding delay and lost data.

[0047] In this embodiment, the system identifies the communication status of the IoT device based on the heartbeat detection preset by the central control host, and then the system determines whether the communication status is offline to execute the corresponding steps; for example, when the system determines that the communication status of the IoT device is offline, the system will consider that the device can no longer communicate normally with the central control host. The system will confirm that the device is indeed offline through multiple consecutive heartbeat detections (for example, no heartbeat signal is received for 3 to 5 consecutive times), rather than temporary signal fluctuations or short communication interruptions, record the device offline time, mark the device status, and avoid affecting the data processing of other online devices. At the same time, an alarm notification is generated through the central control host interface to prompt the operation and maintenance personnel to investigate the specific cause. If the device supports remote maintenance, a firmware restart command can be sent to try to restore the normal operation of the device. When the device supports self-diagnosis, the self-test function is triggered and an error code is returned to further analyze the cause of the fault, and a local cache mechanism is enabled to store key data to avoid data loss during offline. After the device is restored online, the system can execute a data compensation mechanism to batch synchronize historical data during offline to ensure data integrity; for example, when the system determines that the communication status of the IoT device is not offline, the system will consider that the device is still connected to the central control The host maintains normal communication, and the system will collect the timeout information of the IoT device. Based on this timeout information, the data packet loss rate when the data is updated is obtained, and the data packet loss rate is compared with the data reception timestamp preset by the central control host to detect the corresponding delay and lost data; by monitoring the data packet loss rate, the system can promptly detect abnormal conditions of the IoT device during data transmission, such as network congestion, signal interference or equipment failure, thereby improving the reliability of the overall system. At the same time, based on the comparison results of the data packet loss rate and the data reception timestamp, the system can dynamically adjust the data synchronization mechanism, such as increasing the number of data retransmissions, optimizing the data packaging method or enabling differential data transmission to reduce data loss and improve data synchronization efficiency. By detecting the data reception timestamp, the system can calculate the actual data transmission delay, and adjust the data processing priority according to the application scenario of the IoT device (such as real-time monitoring or batch reporting), and optimize the system's response speed. In a large-scale IoT deployment environment, this mechanism can adaptively adjust the data transmission strategy according to the communication status of different devices to ensure that the data of key devices is transmitted first, reduce unnecessary data traffic, and improve the stability and resource utilization of the entire network.

[0048] In this embodiment, the acquisition module further includes: A second detection unit is used to detect the communication quality between the central control host and the IoT device based on the operation log of the IoT device, wherein the operation log specifically includes an average online rate, the number of offline times and the offline time period, and the communication quality specifically includes network delay, packet loss rate and signal strength; A fifth determination unit, configured to determine whether the communication quality reaches a preset quality threshold; The fifth execution unit is used to, if not, identify a preset high packet loss device through the central control host, dynamically adjust the data reporting interval according to the communication quality, and adaptively reduce the data transmission frequency according to the data reporting interval.

[0049] In this embodiment, the system detects the communication quality between the central control host and the IoT device based on the operation log of the IoT device, which specifically includes the average online rate, the number of offline times and the offline time period. The communication quality specifically includes network delay, packet loss rate and signal strength. Then the system determines whether the communication quality reaches a preset quality threshold to execute the corresponding steps. For example, when the system determines that the communication quality between the central control host and the IoT device can reach the preset quality threshold, the system will consider that the current communication status between the IoT device and the central control host is normal, the data transmission is stable, and the requirements of real-time data exchange can be met. When the communication quality reaches the preset threshold, the system will continue Transmit data at the normal data update frequency to ensure that device data is reported on time and is not affected by network factors, ensuring the real-time and integrity of the data. At the same time, according to the actual data update needs of the device, further optimize the frequency of data collection. For example, if the device usage scenario requires high-frequency data updates, the collection frequency can be appropriately increased, or the data transmission time window can be dynamically adjusted according to business needs to ensure efficient use of system resources. In addition, according to the good communication quality of the device, redundant operations such as data retransmission, error checking and data rollback can be reduced, thereby reducing the burden on the central control host and improving the overall system operation efficiency and response speed. For example, when the system determines that the central control host and the IoT device are in communication, the system will automatically send data to the central control host, and ... If the communication quality of the device cannot reach the preset quality threshold, the system will consider that the communication status between the current IoT device and the central control host is abnormal. The system will identify the preset high packet loss device through the central control host, and dynamically adjust the data reporting interval according to different communication qualities. According to the data reporting interval, the data transmission frequency is adaptively reduced; by dynamically adjusting the data reporting interval, the system can avoid frequent data retransmission or error checking caused by high packet loss rate or unstable communication quality, thereby reducing unnecessary bandwidth occupation and system burden. Reducing the data transmission frequency helps to reduce the pressure on the central control host and the network, especially under high load conditions, which can ensure the stability and performance of the system. It can adaptively adjust the data reporting frequency according to the communication quality and packet loss of the device, and can effectively cope with the actual communication conditions of different devices. For example, when the signal is weak or the network fluctuates greatly, the system will automatically reduce the frequency of data collection and transmission to avoid excessive data loss and system abnormalities. This allows the device to maintain connection with the central control host when the communication quality is unstable, without causing serious lag or loss of information. For devices with poor communication quality, the system can effectively reduce the risk of packet loss by reducing the data transmission frequency. A lower frequency helps avoid too frequent transmission requests, aggravating network congestion and leading to more data loss.

[0050] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A protocol-based data communication method for a central control host of the Internet of Things, characterized in that: The following steps are involved: Based on the IoT device preset by the central control host, collect data update parameters of the IoT device, wherein the data update parameters specifically include a data update timestamp and a data value; Determine whether the data update parameter detects a preset update anomaly, wherein the update anomaly specifically includes an unstable update cycle and no update for a long time; If yes, then the frequency devices of the IoT devices are divided according to the data update requirements of the IoT devices, and based on the frequency devices, a unified preset time base is used to calculate the data collection interval, and a local data buffer is added on the gateway end preset by the central control host, and the previous data collection value is allowed to be returned within a preset period of time, wherein the frequency devices specifically include high-frequency devices, medium-frequency devices and low-frequency devices; Determine whether the return of the previous data collection value exceeds a preset number of times; If it exceeds, a preset data refresh request is sent to the central control host. Based on the data refresh request, the preset polling cycle is shortened, the latest data is forcibly obtained, the latest data is compared with the previous data collection value, and the missing estimate of the data update demand is calculated according to the pre-recorded historical data trend, and the missing estimate is filled in the missing data.

2. The protocol-based IoT central control host data communication method according to claim 1, characterized in that: The step of dividing the frequency devices of the IoT devices according to the data update requirements of the IoT devices also includes: Based on the usage requirements of the central control host, the data synchronization frequency of the frequency device is collected; Determining whether the data synchronization frequency matches the data update requirement; If not, the preset data synchronization mechanism is dynamically adjusted according to the cache hierarchical structure preset by the central control host, and the differential data detection preset by the central control host is activated according to the data synchronization mechanism, wherein the cache hierarchical structure specifically includes a local cache layer, an edge computing layer and a cloud storage layer, the data synchronization mechanism specifically includes on-demand synchronization and batch synchronization, and the differential data detection specifically synchronizes only the changed data to reduce data redundancy.

3. The protocol-based IoT central control host data communication method according to claim 1, characterized in that: Before the step of adding a local data buffer on the gateway end preset by the central control host to allow the return of the last data collection value within a preset period of time, the method further includes: Based on the data reporting cycle preset by the central control host, obtain the data update mode of the IoT device, wherein the data update mode specifically includes scheduled reporting, event triggering and on-demand request; Determine whether the data update mode matches the central control host; If not, a data caching strategy for the IoT device is constructed, and the effective time range of the data cache is dynamically adjusted according to the data update frequency. According to the data caching strategy, data caching is restricted to preset non-applicable devices, wherein the non-applicable devices specifically include camera video streams and transient event monitoring devices.

4. The protocol-based IoT central control host data communication method according to claim 1, characterized in that: The step of sending a preset data refresh request to the central control host further includes: Based on the communication data format of the IoT device, detecting the communication mode of the IoT device, wherein the communication data format specifically includes JSON, XML, and binary stream; Determining whether the communication method needs to enable preset encrypted communication; If so, construct the corresponding data request content according to the communication address of the IoT device, and dynamically adjust the request interval of the data request content according to the data update requirement, wherein the communication address specifically includes the IP domain name, port number and authentication method, and the data request content specifically includes specifying the target device ID, setting the data time range and increasing the request priority.

5. The protocol-based IoT central control host data communication method according to claim 1, characterized in that: The step of determining whether the data update parameter detects a preset update anomaly also includes: Based on the preset data update interval of the IoT device, identifying the corresponding data change rate; Determining whether the data change rate exceeds a preset change threshold; If not, the field integrity during data update is obtained, and based on the field integrity, abnormal devices with abnormal data are detected, and preset data re-collection requests are sent to the abnormal devices in batches through the central control host, wherein the field integrity specifically includes field value and field format.

6. The protocol-based IoT central control host data communication method according to claim 1, characterized in that: The step of determining whether the return of the previous data collection value exceeds a preset number of times also includes: Based on the heartbeat detection preset by the central control host, identifying the communication status of the IoT device; Determining whether the communication status is offline; If not, the timeout information of the IoT device is collected, and the data packet loss rate when the data is updated is obtained according to the timeout information, and the data packet loss rate is compared with the data receiving timestamp preset by the central control host to detect the corresponding delay and lost data.

7. The protocol-based IoT central control host data communication method according to claim 1, characterized in that: The step of collecting data update parameters of the IoT devices based on the IoT devices preset by the central control host further includes: Based on the operation log of the IoT device, the communication quality between the central control host and the IoT device is detected, wherein the operation log specifically includes the average online rate, the number of offline times and the offline time period, and the communication quality specifically includes network delay, packet loss rate and signal strength; Determining whether the communication quality reaches a preset quality threshold; If not, the central control host identifies the preset high packet loss device, dynamically adjusts the data reporting interval according to the communication quality, and adaptively reduces the data transmission frequency according to the data reporting interval.

8. A protocol-based IoT central control host data communication system, characterized in that: include: A collection module, used to collect data update parameters of the IoT devices based on the IoT devices preset by the central control host, wherein the data update parameters specifically include a data update timestamp and a data value; A judging module, used to judge whether the data update parameter detects a preset update anomaly, wherein the update anomaly specifically includes an unstable update cycle and no update for a long time; An execution module, for dividing the frequency devices of the IoT devices according to the data update requirements of the IoT devices, unifying the preset time base to calculate the data collection interval based on the frequency devices, adding a local data buffer on the gateway end preset by the central control host, and allowing the return of the last data collection value within a preset period of time, wherein the frequency devices specifically include high-frequency devices, medium-frequency devices and low-frequency devices; A second judgment module is used to judge whether the return of the previous data collection value exceeds a preset number of times; The second execution module is used to send a preset data refresh request to the central control host if it exceeds the limit. Based on the data refresh request, the preset polling cycle is shortened, the latest data is forced to be obtained, the latest data is compared with the previous data collection value, and the missing estimated value of the data update demand is calculated according to the pre-recorded historical data trend, and the missing estimated value is filled into the missing data.

9. The protocol-based IoT central control host data communication system according to claim 8, characterized in that: The execution module further includes: A collection unit, used for collecting the data synchronization frequency of the frequency device based on the use requirements of the central control host; A judging unit, used to judge whether the data synchronization frequency matches the data update requirement; The execution unit is used to dynamically adjust the preset data synchronization mechanism according to the cache hierarchical structure preset by the central control host, and activate the differential data detection preset by the central control host according to the data synchronization mechanism, wherein the cache hierarchical structure specifically includes a local cache layer, an edge computing layer and a cloud storage layer, the data synchronization mechanism specifically includes on-demand synchronization and batch synchronization, and the differential data detection specifically synchronizes only the changed data to reduce data redundancy.

10. The protocol-based IoT central control host data communication system according to claim 8, characterized in that: Also includes: An acquisition module, configured to acquire a data update mode of the IoT device based on a data reporting cycle preset by the central control host, wherein the data update mode specifically includes timed reporting, event triggering, and on-demand request; A third judgment module is used to judge whether the data update mode matches the central control host; The third execution module is used to, if not, construct a data caching strategy for the IoT device, dynamically adjust the effective time range of the data cache according to the data update frequency, and limit data caching to preset non-applicable devices based on the data caching strategy, wherein the non-applicable devices specifically include camera video streams and transient event monitoring devices.

Images