Abnormity reporting method and device of Internet of Things equipment, medium and equipment

Abstract

The invention discloses an abnormity reporting method and device of Internet of Things equipment, a medium and equipment. The abnormity reporting method of the Internet of Things equipment comprises the following steps: acquiring an abnormal state log of the Internet of Things equipment; encoding the abnormal state log based on a preset encoding rule, and identifying a corresponding abnormal state by using a digital sequence to obtain an abnormal state code; determining that the reported connection state is an unavailable state, and buffering abnormal state codes; and determining that the reported connection state is an available state, reporting the buffered abnormal state code, and reporting the real-time abnormal state code. Through the method, the abnormal state of each function of the Internet of Things equipment can be efficiently and accurately acquired, and corresponding coding, buffering or reporting can be performed, so that the data volume of abnormal reporting and processing is reduced, timely and rapid abnormal reporting is realized, the abnormal processing efficiency is improved, the corresponding cost and performance consumption are reduced, and the user experience is improved. And the smoothness and the stability of related business operation can be guaranteed.

Description

Technical Field

[0001] The present application relates to the technical field of Internet of Things, and in particular to a method, device, medium and equipment for reporting abnormalities of Internet of Things devices. Background Art

[0002] With the rapid development of IoT technology, IoT devices are increasingly used in all walks of life. Most of these devices operate automatically according to established rules and are often unattended. Some devices are even deployed on rooftops, high walls, and remote areas. Therefore, when these devices have abnormal working conditions, such as unstable operation, loss of connection and inability to provide services, it will have a serious impact on the normal use of the business and may even cause significant loss of life and property.

[0003] In the current IoT industry, the existing operation and maintenance methods usually record the observed phenomena and inform the equipment manufacturer's technicians. The technicians then travel to the site to reproduce the problem, capture the equipment operation logs during the abnormal phenomenon reproduction process, and filter the relevant status information from them for problem analysis. However, for unstable faults, it is often necessary to stay on site for multiple times or for a long time to collect the operation logs within the reproduction time period. This traditional operation and maintenance support method is very time-consuming and labor-intensive. In addition, when the development of traditional software systems needs to print relevant process status information, the conventional method is to output the information to be printed in text description to the storage medium. This method seems convenient during local development and debugging, but in the mass production version, in order to improve the system operation performance and reserve more available space, a large amount of printing information is often closed or directly discarded. Therefore, once an abnormality occurs in the equipment deployed on site, due to the lack of operation logs, the operation and maintenance personnel usually need to arrange personnel to collect logs related to the equipment operation process on site, which is time-consuming, labor-intensive and extremely inconvenient. Summary of the invention

[0004] The present application mainly provides a method, device, medium and equipment for reporting abnormalities of an Internet of Things device, aiming to solve the technical problem of high operation and maintenance costs of existing Internet of Things devices.

[0005] In order to solve the above technical problems, the technical solution adopted by the present application is: to provide an abnormality reporting method for an Internet of Things device. The abnormality reporting method for an Internet of Things device includes: obtaining an abnormal state log of the Internet of Things device; encoding the abnormal state log based on a preset encoding rule to identify the corresponding abnormal state with a digital sequence to obtain an abnormal state code; determining that the reported connection state is an unavailable state, buffering the abnormal state code; determining that the reported connection state is an available state, reporting the buffered abnormal state code, and / or reporting the real-time abnormal state code.

[0006] In some embodiments, the abnormal status log is encoded based on a preset coding rule to identify the corresponding abnormal status with a preset digital sequence to obtain the abnormal status code, including: extracting device information, functional status information and associated information of the functional status information from the abnormal status log; identifying the device information based on the device identification code; obtaining the status identification code corresponding to the functional status information from a preset status meaning comparison table to identify the functional status information with the status identification code; converting the associated information into an associated information code in a preset standard digital sequence format to identify the associated information with the associated information code; obtaining the abnormal status code based on the device identification code, the status identification code and the associated information code.

[0007] In some embodiments, the associated information includes at least one of a user identity card identification code, an occurrence time of the functional status information, and an abnormal value corresponding to the functional status information.

[0008] In some embodiments, the determination of reporting the connection status as an unavailable status and buffering the abnormal status code includes: determining that a memory variable is not full, storing the abnormal status code in the memory variable; determining that the memory variable is full and determining that the cache file is not full, storing the abnormal status code in the cache file; determining that both the memory variable and the cache file are full, and discarding the abnormal status code.

[0009] In some embodiments, determining that the reported connection state is an available state, reporting the buffered abnormal state code, and / or reporting the real-time abnormal state code includes:

[0010] Determine that the length of the memory variable is equal to or greater than the preset reporting number, take out the buffered abnormal status codes from the memory variable in sequence, and report them; determine that the length of the memory variable is less than the preset reporting number, end the abnormal status reporting of the memory variable; confirm that the cache file is not empty, take out the buffered abnormal status codes one by one from the cache file in sequence, and report them; confirm that the reporting is completed, clear the memory variable and the abnormal status codes that have been reported in the cache file.

[0011] In some embodiments, the determining that the reported connection status is an unavailable status, buffering the abnormal status code, and the determining that the reported connection status is an available status, reporting the buffered abnormal status code, and / or reporting the real-time abnormal status code, also include: starting a supplementary reporting timer, wherein the supplementary reporting timer is used to periodically obtain the reported connection status.

[0012] In some embodiments, the abnormal status log includes at least one of an error return value exception, a no result return value exception, a large fluctuation exception, and a state mutation exception.

[0013] To solve the above technical problems, another technical solution adopted in the present application is: to provide an abnormality reporting device for an Internet of Things device, the abnormality reporting device comprising: an acquisition module, used to obtain the abnormal status log of the Internet of Things device; a coding module, used to encode the abnormal status log based on a preset coding rule, so as to identify the corresponding abnormal status with a digital sequence, and obtain the abnormal status code; a buffer module, used to determine that the reported connection status is an unavailable state, and buffer the abnormal status code; a reporting module, used to determine that the reported connection status is an available state, report the buffered abnormal status code, and / or report the real-time abnormal status code.

[0014] In order to solve the above technical problems, another technical solution adopted in the present application is: providing a storage medium, on which program data is stored, characterized in that when the program data is executed by a processor, the steps of the abnormal reporting method of the Internet of Things device as mentioned above are implemented.

[0015] In order to solve the above technical problems, another technical solution adopted in the present application is: to provide a computer device, which includes a processor and a memory connected to each other, the memory stores a computer program, and when the processor executes the computer program, it implements the steps of the abnormal reporting method of the Internet of Things device as mentioned above.

[0016] The beneficial effects of the present application are as follows: Different from the prior art, the present application discloses a method, device, medium and device for reporting abnormalities of Internet of Things devices. The present application identifies the abnormal state reflected by the abnormal state log through a digital sequence to obtain the abnormal state code, which can greatly reduce the consumption of log data on the device operating performance and the storage space occupied by the Internet of Things device, and reduce the amount of data required for abnormal reporting and processing. Buffering or reporting according to the reported connection state can provide a certain buffering effect for the reporting of the abnormal state, retain the integrity of the abnormal state information as much as possible, achieve timely and rapid abnormal reporting, reduce the occurrence of underreporting, improve the efficiency of abnormal handling, reduce the corresponding cost and performance consumption, can quickly analyze remotely, speed up the location and repair efficiency of faults, and is conducive to improving troubleshooting efficiency. It provides a data basis for early warning and predictive maintenance of equipment failures, and can effectively ensure the smoothness and stability of related business operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work, among which:

[0018] Figure 1 This is a flow chart of an embodiment of a method for reporting abnormalities of an Internet of Things device provided by the present application;

[0019] Figure 2 yes Figure 1 A schematic flow chart of an embodiment of step 20 in the embodiment;

[0020] Figure 3 yes Figure 1 A schematic flow chart of an embodiment of step 30 in the embodiment;

[0021] Figure 4 yes Figure 1 A schematic diagram of a flow chart of an embodiment of step 40 in the embodiment;

[0022] Figure 5 It is a structural diagram of an embodiment of an abnormality reporting device for an Internet of Things device provided by the present application;

[0023] Figure 6 It is a structural schematic diagram of an embodiment of a storage medium provided by the present application;

[0024] Figure 7 It is a structural diagram of an embodiment of a computer device provided by the present application. DETAILED DESCRIPTION

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

[0026] The terms "first", "second", "third" in the embodiments of the present application are only used for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Thus, the features defined as "first", "second", "third" can expressly or implicitly include at least one of the features. In the description of the present application, the meaning of "multiple" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices.

[0027] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0028] This application provides a method for reporting abnormalities of an IoT device. Figure 1 , Figure 1 1 is a flow chart of an embodiment of a method for reporting an abnormality of an Internet of Things device provided by the present application. The method for reporting an abnormality of an Internet of Things device includes:

[0029] Step 10: Get the abnormal status log of IoT devices.

[0030] In the operation of IoT devices, abnormal data status is usually fed back, and the operation status, operation history, error information and warnings of the devices and components related to the abnormal status are recorded through logs (Log), thereby generating abnormal log status. The abnormal status log in the IoT device can be obtained by accessing the log file stored locally or in the cloud, configuring the corresponding monitoring mechanism or using log aggregation tools. This embodiment obtains the abnormal status log for subsequent analysis and processing of the abnormal status.

[0031] Optionally, in some embodiments, the abnormal status log includes at least one of an error return value exception, a no result return value exception, a large fluctuation exception, and a state mutation exception.

[0032] There are usually a variety of abnormal situations with non-normal values ​​in the abnormal log, including but not limited to at least one of the following: error return value abnormality, no result return value abnormality, large fluctuation abnormality and state mutation abnormality. Among them, error return value abnormality refers to the abnormal situation that the device cannot complete the given operation due to internal or external factors when performing a task, and thus returns an error code or information; no result return value abnormality refers to the abnormal situation that the device does not produce any output within the expected time, which may be caused by reasons such as device failure, communication interruption or task execution failure; large fluctuation abnormality refers to the abnormal situation that the key performance indicators of the device, such as temperature, pressure, flow, etc., fluctuate violently beyond the normal range during operation; state mutation abnormality refers to the abnormal situation that the device state changes drastically in a short period of time, and the change does not conform to the logic of normal operation of the device or the trend of historical data.

[0033] For example, memory application failure, device loading (mounting) failure, USB (Universal Serial Bus) port change, SIM (Subscriber Identity Module) card data reading failure, DNS (Domain Name System) resolution error, network connection timeout, firmware download failure, AP (Access Point) device connection failure, voltage overload, signal coverage strength is too low, no available network cell, etc. will all produce at least one of the above abnormal value abnormal situations. By obtaining abnormal status logs including these abnormal value data and conducting corresponding analysis, potential problems of IoT devices can be discovered and handled in a timely manner, further ensuring the stable operation of the equipment and the accuracy of the data. The abnormal values ​​in these situations can be used as associated information of the functional status information in the future, so that the corresponding equipment failure early warning and predictive maintenance work can more accurately understand the abnormal situation.

[0034] Step 20: Encode the abnormal state log based on a preset encoding rule to identify the corresponding abnormal state with a digital sequence to obtain the abnormal state code.

[0035] In this embodiment, the preset coding rule is a pre-set coding method for converting the information in the abnormal status log into a digital sequence. It can be a specific algorithm, a set of predefined mapping tables, or a coding scheme based on specific field processing logic. In practical applications, such coding rules can be flexibly designed to adapt to different types of IoT devices and abnormal situations to ensure the universality and scalability of abnormal reporting. As long as the abnormal status log can be converted into a digital sequence format, it is understandably within the protection scope of this embodiment.

[0036] In this embodiment, by encoding the abnormal state log, complex abnormal information can be quickly converted into a digital form that is easy to process and transmit. For example, key information such as error code, error description, occurrence time, device identification, etc. in the abnormal state log will be extracted and converted into a digital sequence in a unified format. This encoding method can simplify the storage and processing of abnormal information, thereby effectively improving the efficiency and accuracy of abnormal processing, not only helping to quickly identify and locate problems, but also facilitating the sharing and exchange of abnormal information between different systems and devices. In addition, the design of the coding rules also takes into account the classification and priority of abnormal states, so that when abnormal reports are reported, they can be sorted according to the severity of the abnormalities, giving priority to more urgent problems. In this way, it can be ensured that when the Internet of Things device encounters an abnormal situation, it can promptly and accurately send an alarm to the maintenance personnel or system, thereby reducing the equipment downtime and improving the overall operation and maintenance efficiency.

[0037] Optional, see Figure 2 In one embodiment, the abnormal state log is encoded based on a preset encoding rule to identify the corresponding abnormal state with a digital sequence to obtain the abnormal state code, which can be performed as follows:

[0038] Step 21: Extract device information, function status information, and associated information of the function status information from the abnormal status log.

[0039] Step 22: Identify device information based on the device identification code.

[0040] Step 23: Obtain the state identification code corresponding to the functional state information from a preset state meaning comparison table, and use the state identification code to identify the functional state information.

[0041] Step 24: Convert the associated information into an associated information code in a preset standard digital sequence format, so as to identify the associated information with the associated information code.

[0042] Step 25: Based on the device identification code, the status identification code and the associated information code, obtain the abnormal status code.

[0043] In this optional embodiment, the device information in the abnormal state log refers to the detailed information used to uniquely identify the specific device in the abnormal state, which usually includes but is not limited to the model, serial number, installation location number, manufacturer information of the device, and may also include the network address (such as IP address) or physical address (such as MAC address) of the device, etc. This information can be used to quickly locate and analyze the cause of the problem device, which is conducive to taking more targeted maintenance measures. By extracting device information from the abnormal state, it can be ensured that the abnormal state can be accurately associated with the specific device during the encoding process, which is convenient for subsequent corresponding tracking and management. For example, if a certain abnormal state log records "Robot No. 5 on production line A is running abnormally", then the extracted device information should include the model, serial number and specific location of the robot on the production line.

[0044] In this optional embodiment, after the device information is extracted, the corresponding device can be identified by the device identification code, so as to identify the device information with a more concise and unique digital sequence, ensuring that any abnormal state can be quickly and accurately associated with the corresponding device. The device identification code can specifically be the device's IMEI code (International Mobile Equipment Identity), SN code (Serial Number) or other unique identification code in the device, etc. These digital sequence codes can uniquely identify the corresponding IoT device, and can also bind the unique device identification code to the relevant information of other devices through information registration, so that the data under the abnormal state of the corresponding IoT device can be tracked and processed more accurately later.

[0045] In this optional embodiment, the functional status information in the abnormal status log refers to detailed information describing whether one or more functions of the device are operating normally at a specific time point or time period, how efficient the operation is, and whether there are abnormalities or faults. This information usually includes but is not limited to the start / stop status of the function, operating parameters such as temperature and pressure, functional outputs such as output and quality, and any error codes or warning signals directly related to the operation of the function. The functional status information can reflect the real-time status of the device during operation and is an important basis for analyzing the abnormal state of the device. By monitoring and recording this functional status information, abnormal behavior of the device, such as abnormal fluctuations in performance indicators, can be discovered in time, so that corresponding maintenance measures can be taken. In the abnormal status log, the functional status information usually forms a complete abnormal status description together with the device information and related information, providing detailed data support for subsequent abnormal analysis and processing.

[0046] In this optional embodiment, the preset status meaning comparison table is a reference data for describing the digital sequence identification corresponding to the functional status information of different abnormal states, and is intended to provide a standardized digital sequence representation method to describe the functional status of the device under abnormal circumstances. The preset status meaning comparison table can be used at the beginning of the software system development of the Internet of Things device to classify the various functions of the system, and uniformly compile and register the status codes required under each functional category, and share the same relationship record table with development, operation and maintenance personnel for reference, so that relevant personnel can quickly determine the corresponding functional module and status code meaning based on the status identification code of the digital sequence. In addition, the preset status meaning comparison table can also provide an interface for modification or addition and subtraction. If there is a newly added functional module or an existing functional module needs to add a new status code, it only needs to update the relevant records in the status meaning comparison table, which is highly compatible and flexible.

[0047] In this embodiment, the status identification code in the preset status meaning comparison table can be a digital sequence that can simultaneously identify the abnormal function module and the type of the corresponding abnormal state, or it can be a digital sequence that only needs to indicate the abnormal type in a specific subdivision. For example, in the communication of the TCP (Transmission Control Protocol) module of the Internet of Things device, it includes a series of functions such as creating a socket, establishing a connection, and receiving and sending data. The digital sequence 2001 is used to identify the function of creating a socket, the digital sequence 3014 is used to identify the function of receiving and sending data such as the message queue telemetry transmission (Message Queuing Telemetry Transport, MQTT), and the digital sequence 4015 is used to identify the over-the-air download software upgrade (Firmware Furthermore, if during the execution of the socket creation function, the digital sequence 20101 is used to identify the abnormal situation that the local socket handle fails to be created, then the digital sequence 200120101 can be used to identify the corresponding abnormal state, and the digital sequence 20103 is used to identify the abnormal situation that the IP address is invalid, then the digital sequence 200120103 can be used to identify the corresponding abnormal situation. In addition, since the identification of the abnormal state can be directly determined to be unique, 20101 can also be directly used to identify the abnormal situation that the local socket handle fails to be created in the socket creation function, and 20103 can be used to identify the abnormal situation that the IP address is invalid in the socket creation function.

[0048] In this optional embodiment, the status identification code corresponding to the functional status information can be accurately obtained through the preset status meaning comparison table, and the functional status information can be identified by the status identification code. The preset status meaning comparison table standardizes the identification of each functional module and different operating states, and converts the functional status information into one or more digital sequences that can accurately reflect its functional status. Subsequently, by comparing the status identification code with the status meaning comparison table, the detailed information of the abnormality or fault corresponding to the abnormal state can be quickly determined.

[0049] In this optional embodiment, the associated information of the functional status information refers to some additional information that is associated with the functional status information but does not completely belong to the functional status itself, which helps to further clarify the specific situation and cause of the abnormal state. For example, the associated information may include the operating environment data of the equipment, the operator's records, maintenance logs, historical fault records, etc. By converting these associated information into associated information codes in a standard digital sequence format, the integrity and accuracy of the abnormal state coding can be ensured, which is convenient for subsequent analysis and processing of abnormal situations.

[0050] Optionally, in some embodiments, the associated information includes at least one of a user identity card identification code, an occurrence time of the function status information, and an abnormal value corresponding to the function status information.

[0051] In this optional embodiment, the user identity card identification code is a digital sequence used to uniquely identify the SIM card of the Internet of Things device, such as ICCID (Integrated Circuit Card Identity), IMSI (International Mobile Subscriber Identity) or MSISDN (MobileStation International Subscriber Directory Number). These identification codes not only help track and manage the connection status of the Internet of Things device, but also can quickly locate the user or responsible person using the device when an abnormal state occurs, thereby accelerating the resolution of the problem.

[0052] In this optional embodiment, the appearance time of the functional status information indicates the time or time period when the corresponding abnormality occurs. The digital serialization of the appearance time can be done by removing the corresponding connector or text description. For example, the appearance time in the log is recorded as 2024-10-1009:40:32:450, which can be converted into the format of YYYYMMDDHHMMSSSSS, that is, 20241010094032450. The appearance time of the functional status information can be used to analyze the development trend of the abnormal state, which is of great significance for judging whether the abnormality recurs and formulating preventive measures, and provides a strong time basis for subsequent analysis and processing.

[0053] In this optional embodiment, the abnormal value corresponding to the functional status information is the value of the abnormal related indicator data, including but not limited to the abnormal readings of physical quantities such as temperature, pressure, current, voltage, and the numerical representation of any performance indicator or error code directly related to the functional status. For example, when the voltage is overloaded, it may be the value 50, 500, 5000, etc. representing 50V voltage, accurate to different digits. For another example, when the signal coverage strength is low, it may be the value 130, 0130, etc. representing -130dBm, and the positive and negative values ​​are represented by 0, 1 or other values. For another example, for some values, a setting similar to the aforementioned state meaning comparison table can also be adopted, and a digital sequence is matched with the abnormal value situation, such as memory application failure is marked with sequence 00, application long waiting is marked with sequence 01, and the instruction obtained by the application is lost with 10, etc. The accurate recording and analysis of abnormal values ​​helps to deeply understand the essential cause of the abnormal state and provide data support for the formulation of targeted solutions.

[0054] In this optional embodiment, the corresponding associated information code is a digital sequence determined by comprehensively considering at least one of the user identity card identification code, the appearance time of the function status information and the abnormal value corresponding to the function status information. For example, the user identity card identification code is determined to be 12345678910, the digital sequence of the appearance time is determined to be 20241010094032450, and the digital sequence of the abnormal value is determined to be 0130, then the corresponding associated information code can be 12345678910202410100940324500130.

[0055] In this optional embodiment, after obtaining the above-mentioned device identification code, status identification code and associated information code, a standardized abnormal status code can be constructed based on the digital sequence of these key information. For example, these sequences can be combined to obtain the abnormal status code, and an abnormal status code in the form of "device identification code + status identification code + associated information code" can be obtained. The same type of digital sequence uses the same size of bytes for storage and processing. For example, when using IMEI, the size of the device identification code can be 15 bytes, and at this size, various forms of device identification codes can be better stored and processed.

[0056] In this optional embodiment, the abnormal state coding can also adopt other mapping methods according to the device identification code, the state identification code and the associated information code. For example, according to actual needs, only part or all of the information can be used for coding, such as using only the device identification code and the state identification code to construct the abnormal state coding. At the same time, in order to improve the efficiency and accuracy of the coding, the priority and classification of the abnormal state can also be considered in the construction process of the abnormal state coding to ensure that the abnormal state can be sorted according to the severity of the abnormality when the abnormality is reported. For example, different priority identification codes can be assigned to different types of abnormal states, such as emergency failures, general failures and warning information, so that priority information can be included in the abnormal state coding, so that maintenance personnel or systems can give priority to more urgent problems. In addition, the abnormal state coding can also be combined with timestamp information to record the specific time when the abnormality occurs, which has important reference value for analyzing the frequency and trend of abnormal occurrences, predicting potential problems, and formulating preventive measures.

[0057] Step 30: Determine that the reported connection status is unavailable, and buffer the abnormal status code.

[0058] In this embodiment, the reported connection status is the status of whether the current IoT device is connected to the network platform that receives the response report information. This status can be detected by the built-in network module of the device, or confirmed by the communication protocol with the network platform, or obtained through a specific status monitoring and query mechanism. When it is detected that the reported connection status is unavailable, it means that there is a problem with the communication link between the IoT device and the network platform, which may be caused by network instability, device-side network configuration errors, network platform service abnormalities, or mismatches in the communication protocols between the two. In order to ensure the robustness and maintainability of IoT devices, this implementation buffers the abnormal status codes to cope with the unavailable status situation.

[0059] In this embodiment, the buffering abnormal state coding method can be a local caching method such as memory cache, application layer cache of database, file cache and in-heap cache, or a combination of multiple caching methods. By buffering the abnormal state coding, it can be ensured that even if the connection between the device and the network platform is temporarily interrupted, the abnormal information will not be lost. Then once the network connection is restored, the buffered abnormal state coding can be sent to the predetermined server or platform through the network to ensure that the abnormal information can be reported and processed in time. In addition, in order to further improve the reliability of abnormal reporting, corresponding state re-detection mechanism and reporting processing retry mechanism and other fault-tolerant mechanisms can also be configured, such as timed detection and reporting of connection status, and automatically trying to resend the abnormal state coding after reporting failure, thereby effectively reducing the loss of abnormal information caused by network fluctuations or temporary failures, and retaining the integrity of abnormal state information as much as possible, which is conducive to improving the stability and reliability of the entire Internet of Things system.

[0060] Optional, see Figure 3 In one embodiment, determining that the reported connection state is unavailable and buffering the abnormal state code may be performed as follows:

[0061] Step 31: Determine that the memory variable is not full, and store the abnormal status code in the memory variable.

[0062] Step 32: Determine whether the memory variable is full and whether the cache file is not full, and store the abnormal status code in the cache file.

[0063] Step 33: Determine that the memory variables and cache files are full, and discard the abnormal status code.

[0064] In this optional embodiment, a double buffering mechanism is specifically implemented, that is, the abnormal status codes that cannot be effectively reported are processed through the buffering of memory variables and cache files, wherein the memory variables are the data in the running memory space, and the cache files are the file data in the local storage medium of the device. By configuring the cache space for the running memory and the storage medium respectively, the size will be determined according to the actual capacity of the local storage and the amount of encoded status data. The data in the running memory space can support reading and sending operations while receiving the status code, so as to realize the rapid reception and recycling of the status code information transmitted by other components, and the cache file can better play the role of buffering when the abnormal status code and other data are generated in large quantities and there is no network connection or the sending speed is slow, so as to maintain the integrity of the abnormal status information as much as possible.

[0065] In this optional embodiment, when buffering, priority is given to whether the memory variable is full to ensure that the running memory can be efficiently used for fast data processing. The access speed of the memory variable is usually faster than the cache file, so using it as the preferred buffer area can significantly improve the efficiency of receiving and processing the abnormal state code. When the memory variable is not full, the abnormal state code is directly stored in the memory, so that these codes can be quickly sent out when the network connection is restored. However, considering that the Internet of Things device may face a long network interruption or a large number of abnormal state codes are generated, the capacity of the memory variable is limited. Therefore, when the memory variable is full, the storage status of the cache file will be checked. As a second-layer buffering mechanism, the cache file has a relatively large capacity and can store more abnormal state codes. If the cache file is not full, the new abnormal state code will be stored in the cache file to ensure that the abnormal information will not be lost even in the case of a long network interruption.

[0066] In this optional embodiment, when both the memory variables and the cache files are full, the IoT device faces the limit of storage space. In this case, in order to protect the normal operation of the device and avoid serious problems such as memory overflow, the new abnormal state code will be discarded. Although this will cause some abnormal information to be lost, it is a necessary sacrifice in extreme cases where device resources are limited and the network is unavailable for a long time to ensure the stability and availability of the device. In addition, in order to optimize the performance of this double buffering mechanism, the device can also implement some additional strategies. For example, an automatic cleanup strategy for memory variables and cache files can be set. When the network recovers and successfully reports a certain number of abnormal state codes, the space occupied by the reported codes is automatically cleaned up, or the cached abnormal state codes are cleared from old to new according to the time of occurrence of the abnormal state codes according to the timeout rules or the timed batch clearing method, so as to provide storage space for the new abnormal state codes. At the same time, the device can also dynamically adjust the size of the memory variables and cache files used to store the abnormal state codes according to the actual application scenarios and requirements to achieve the best buffering effect and performance.

[0067] This optional embodiment can effectively manage the storage and reporting process of abnormal status codes through the implementation of the above-mentioned double buffering mechanism, ensuring that abnormal information will not be lost even when the network connection is unstable or interrupted. Through this mechanism, the IoT device can continuously monitor its own status and quickly report the previously accumulated abnormal status codes after the connection is restored, thereby improving the reliability and response speed of the entire IoT device. In addition, the double buffering mechanism can also reduce the load on the network platform, and subsequently report through the set maximum number of single transmissions, avoiding network congestion or server overload caused by the concentrated reporting of a large amount of abnormal information, further improving the stability of the device and user experience.

[0068] Step 40: Determine that the reported connection state is an available state, report a buffered abnormal state code, and / or report a real-time abnormal state code.

[0069] In this embodiment, when the reported connection status is an available status, the buffered abnormal status code and the real-time generated abnormal status code can be sent to a predetermined server or platform through the network, that is, the report is made according to the actual situation of buffering and real-time acquisition. When the reporting channel is crowded and inefficient, the abnormal status code acquired in real time can be buffered first, and then reported in coordination with other buffered abnormal status codes. There are many ways to report. For example, the abnormal status code can be reported in sequence according to one or more indicators such as the timestamp, priority, and business relevance corresponding to the abnormal status code. The abnormal status code can be reported in batches according to the capacity of the reported transmission channel and according to the packet size, or the abnormal status code can be processed by verification algorithm, compression algorithm, encryption algorithm, etc. to ensure the accuracy and security of the abnormal status code.

[0070] In this embodiment, after the abnormal state code is reported to the server or platform, the server or platform will perform corresponding processing. For example, the digital sequence can be converted back to the original device information, functional status information and related information through decoding processing. Based on this information, the server or platform can classify and prioritize the abnormalities to facilitate rapid identification and handling of emergency problems. In addition, the server or platform can also record the reception time of the abnormal state code, and compare and analyze it with the timestamp of the abnormal occurrence, so as to evaluate the response time and service quality of the abnormal processing. During the abnormal processing, the server or platform can use various information in the abnormal state code to quickly locate and track the abnormal situation. For example, the user identity card identification code can quickly locate the relevant user or responsible person for communication and coordination. At the same time, the abnormal value corresponding to the functional status information in the abnormal state code can be used as an important basis for analyzing the cause of the abnormality and formulating solutions. For example, if the abnormal value indicates that the device voltage is overloaded, the power supply system can be further checked, or the power management strategy of the device can be adjusted. After the server or platform handles the abnormality, the processing result will be fed back to the IoT device, or recorded in the maintenance log for subsequent analysis and auditing. In addition, in order to continuously improve the stability and reliability of IoT devices, the server or platform can also perform big data analysis based on the data from exception processing to identify potential risk points and improvement directions, thereby optimizing the operating environment and maintenance strategies of IoT devices.

[0071] Optional, see Figure 4 In one embodiment, determining that the reported connection state is an available state, reporting the buffered abnormal state code, and reporting the real-time abnormal state code can be performed according to the following steps:

[0072] Step 41: Determine whether the length of the memory variable is equal to or greater than the preset reporting number, take out the buffered abnormal status codes from the memory variable in sequence, and report them.

[0073] Step 42: Determine that the length of the memory variable is less than the preset reporting number, and end the abnormal state reporting of the memory variable.

[0074] Step 43: confirm that the cache file is not empty, take out the buffered abnormal status codes one by one from the cache file, and report them.

[0075] Step 44: Confirm that the reporting is complete, and clear the abnormal status codes that have been reported in the memory variables and cache files.

[0076] In this optional embodiment, the reporting process is specifically controlled by setting a preset reporting number, which is a variable used to control the reporting behavior and strategy of the status code. It determines how the status code is reported to the cloud platform, such as the frequency of reporting, the amount of data reported each time, etc. There will be a default value when the software is written, such as 1. In addition, the platform will provide a remote instruction to modify the default value, such as changing from 1 to 10. In addition, the unit will verify this parameter to provide a protection mechanism, such as its maximum settable value is 10. When the received setting is greater than 10, such as 11, 12, 13, the value is automatically corrected to 10 to ensure that the preset reporting number is in a reasonable and correct range. This value is usually dynamically adjusted according to the size of the memory variable and the cache file, the size of a single abnormal state code, the number of abnormal state codes to be reported, and the congestion of the reporting channel. For example, when the memory variable is large, the preset reporting number can be increased, and when the single abnormal state code is large, the preset reporting number can be reduced. If the value is set to 0, it usually means that the reporting function is turned off, no reporting processing is performed, and no buffer mechanism is required. The collected abnormal status codes can be directly discarded.

[0077] In this optional embodiment, during the reporting process, it will first be checked whether the number of abnormal state codes stored in the memory variable reaches or exceeds the preset reporting number. Once the conditions are met, the reporting mechanism will be started, and the abnormal state codes will be taken out from the memory variable in accordance with the setting of the preset reporting number, and sent to the predetermined server or platform through the network. This process ensures that the abnormal state code can be reported in a timely and effective manner, while avoiding the processing delay caused by too many abnormal state codes in the memory variable. If the number of abnormal state codes stored in the memory variable does not reach the preset reporting threshold, the reporting process will not be started. At this time, the device will suspend the reporting operation of the abnormal state code in the memory variable, and wait for more abnormal state codes to be buffered or generated in real time before reporting. This mechanism helps to reduce unnecessary network transmission, and can reasonably balance the protocol overhead of the data transmission of the abnormal state code and the resource occupation of the fragmented transmission, ensuring that the abnormal state code is only reported when it accumulates to a certain number, while saving traffic to the greatest extent, it also reduces the risk of losing data as much as possible, and can effectively improve the effectiveness and reliability of the reporting transmission.

[0078] In this optional embodiment, if it is confirmed that the cache file is not empty, the buffered abnormal status codes are taken out one by one from the cache file and reported. When the number of abnormal status codes in the memory variable is insufficient for reporting, or the memory variable is full and there are abnormal status codes to be reported in the cache file, the status of the cache file is checked. If there are abnormal status codes in the cache file, these codes will be taken out from the cache file in sequence and sent to the server or platform through the network. After the abnormal status code is successfully reported to the server or platform, a cleanup operation of the memory variable and the cache file will be performed to release the space occupied by the abnormal status codes reported in the memory variable and the cache file. It ensures that the device can continuously and effectively manage the storage and reporting of abnormal status codes, avoids the loss of abnormal information or the degradation of device performance due to insufficient storage space, and can provide sufficient storage space for new abnormal status codes, thereby maintaining the stable operation and efficient exception handling capabilities of the Internet of Things device.

[0079] Optionally, in some embodiments, before determining that the reported connection status is an unavailable status, buffering the abnormal status code, and determining that the reported connection status is an available status, reporting the buffered abnormal status code, and / or reporting the real-time abnormal status code, it also includes: starting a supplementary reporting timer, wherein the supplementary reporting timer is used to periodically obtain the reported connection status.

[0080] In this embodiment, in the above steps 30, 40 and the corresponding optional embodiments, the reported connection status can be obtained regularly through a supplementary reporting timer. The supplementary reporting timer periodically checks the reported connection status, for example, every 10 minutes, every 30 minutes, and every 60 minutes. After the supplementary reporting timer is started, the device will periodically try to obtain the reported connection status to determine whether the abnormal state code can be reported. If the reported connection status becomes available within the inspection period of the supplementary reporting timer, the device will immediately perform the reporting operation and send the buffered abnormal state code and / or the real-time generated abnormal state code to the predetermined server or platform. The start of the supplementary reporting timer can be configured by the control unit of the Internet of Things device according to the needs of the actual application scenario. Through the periodic inspection mechanism of the supplementary reporting timer, it can be ensured that even if the connection between the device and the network platform is temporarily interrupted, the network recovery can be discovered in time and the abnormal information can be quickly reported, thereby improving the stability and reliability of the entire Internet of Things device and network platform or system, effectively reducing the loss of abnormal information caused by network fluctuations or temporary failures, and ensuring the integrity of abnormal state information. At the same time, the periodic check of the supplementary reporting timer can also help the device respond to changes in network status in a timely manner, avoiding the backlog of abnormal information caused by long-term failure to detect the network availability status, thereby improving the exception handling efficiency and user experience of IoT devices.

[0081] In this embodiment, the abnormal status code can be obtained by setting the status code collection interface of the status code management unit. The status code management unit is specifically responsible for the collection, packaging, transmission, storage and supplementary reporting of each status code. The status code collection interface provided by it is called by other functional components in the IoT device when an abnormality occurs. When the unit receives the abnormal status log transmitted by other components, it encapsulates the key data according to the aforementioned preset coding rules. After the encapsulation is completed, the abnormal status code is obtained, and it is reported to the platform or cached according to the aforementioned steps 30 and 40, and the log data is supplemented under the conditions that meet the requirements. The status code collection interface of the status code management unit is called by multiple functional components, and the corresponding abnormal status code is generated when it is called by the functional component. The prototype of the interface can include multiple parameters. In addition to obtaining the abnormal status code, the type of the abnormal status code, the data information of the abnormal status code such as the length, the number of functional status information corresponding to the same device identifier, etc. can also be obtained. The interface can be defined by the function void collect_status_code(unsigned short int type, unsigned short int code, char*msg). At the same time, since the interface may be called simultaneously by multiple functional components in the device, synchronization operations are required to ensure thread safety, ensure exclusive access to shared resources at any time, and avoid errors caused by multiple simultaneous accesses.

[0082] In this embodiment, for the above-mentioned collection and reporting process, the present application provides a specific embodiment as an example of the implementation of the above-mentioned step 30 and step 40, and its specific operation includes the following steps:

[0083] a. Confirm that the functional unit is started, initialize the memory variable CodeBuff and the cache file StatusCodefile, and skip it if the cache file StatusCodefile already exists. Among them, the length of the device identification code in the status exception code is set to 15 bytes, and the length of the status identification code and related information code of the corresponding single abnormal state is 85 bytes. This solution will subsequently define the combination of the status identification code and the related information code as the status code. Since the device identification code is fixed, it only needs to be reported or preset in advance during the initialization phase. This solution limits the size of the memory variable and the cache file to 3400B, that is, 85*40B, so the two can each accommodate a total of 40 status code sizes;

[0084] b. The functional unit continues to run the next step; start the supplementary reporting timer A to supplement the status code data in the cache file; the supplementary reporting timer A monitors and determines the reporting connection status every 30 minutes: if it is not available, continue to count the next cycle; if it is available, if CodeBuff is full, report the CodeBuff data according to the subsequent step f, otherwise, if the cache file StatusCodefile is not empty, read the status code data one by one from it, call the status code acquisition interface, that is, the transfer and subsequent sending process in step c. After all readings are completed, release the acquisition interface, clear the cache file content, and continue to count the next cycle.

[0085] c. Receive status codes collected by other functional components through the collection interface;

[0086] d. Determine the value of the preset status code reporting number sendtype. If it is 0, it means that the reporting function is turned off, the collected status code is directly discarded, and the subsequent steps are ended; if it is not 0, run the next step. Among them, when the sendtype value is greater than the maximum value 10, it is automatically corrected to 10;

[0087] e. Determine the length of CodeBuff content. If it is not full, that is, it does not reach the 40 items set in this example, copy the status code data transmitted by the interface to CodeBuff and trigger the next step; if the space is full, go to step g;

[0088] f. Determine the reporting connection status. If it is not available, the reporting ends and the received status code information is temporarily stored in the memory variable; if it is available, determine the size of CodeBuff and sendtype. If the length of CodeBuff is equal to or greater than the sendtype value, take out sendtype data from CodeBuff in sequence and send them, and clear the corresponding data in CodeBuff at the same time, and the reporting ends; if it is less than the sendtype value, the reporting ends and waits for the next data transmission from the collection interface to arrive and trigger the execution;

[0089] g. Determine the size of the cache file StatusCodefile. If it is full, that is, the maximum length of the status code is reached, that is, it reaches 40 items set in this example, then it will be discarded and the report will end; if it is not reached, it will be appended to the file and the report will end;

[0090] h. Determine the reporting connection status. If it is not available, the reporting ends. If it is available, read the status code data one by one from the cache file StatusCodefile, call the status code collection interface to write CodeBuff. If the length is equal to or greater than the sendtype value, take out sendtype data from CodeBuff and send it, and clear the corresponding data in CodeBuff. If it is less than the sendtype value, the reporting ends, and wait for the collection interface to pass more data to sendtype before sending it together.

[0091] i. Before the functional unit exits, it determines the length of the CodeBuff content. If it is empty, it exits directly; if it is not empty, it jumps to g.

[0092] It should be noted that the above steps a to i are only used as examples of the contents of the aforementioned embodiments, and the names of specific parameters and variables are only used as exemplary descriptions, and are not specific limitations on the relevant numerical values. The technical means and effects thereof can be specifically referred to the descriptions of the aforementioned steps 10 to 40 and related optional embodiments, and this application will not elaborate on them here.

[0093] See also Figure 5 , Figure 5 It is a structural diagram of an embodiment of an abnormality reporting device for an Internet of Things device provided by the present application.

[0094] The abnormality reporting device 50 includes: an acquisition module 51, which is used to obtain the abnormal status log of the Internet of Things device; an encoding module 52, which is used to encode the abnormal status log based on a preset encoding rule, so as to identify the corresponding abnormal status with a digital sequence and obtain the abnormal status code; a buffer module 53, which is used to determine that the reported connection status is an unavailable state, and buffer the abnormal status code; a reporting module 54, which is used to determine that the reported connection status is an available state, report the buffered abnormal status code, and / or report the real-time abnormal status code.

[0095] Optionally, in some embodiments, the abnormal status log includes at least one of an error return value exception, a no result return value exception, a large fluctuation exception, and a state mutation exception.

[0096] Optionally, in some embodiments, the encoding module 52 is specifically used to: identify device information based on the device identification code; obtain the status identification code corresponding to the functional status information from a preset status meaning comparison table, and identify the functional status information with the status identification code; convert the associated information into an associated information code in a preset standard digital sequence format, and identify the associated information with the associated information code; obtain the abnormal status code based on the device identification code, the status identification code and the associated information code.

[0097] Optionally, in some embodiments, the associated information includes at least one of a user identity card identification code, an occurrence time of the function status information, and an abnormal value corresponding to the function status information.

[0098] Optionally, in some embodiments, the buffer module 53 is specifically used to: determine that the memory variable is not full, and store the abnormal status code in the memory variable; determine that the memory variable is full and that the cache file is not full, and store the abnormal status code in the cache file; determine that both the memory variable and the cache file are full, and discard the abnormal status code.

[0099] Optionally, in some embodiments, the buffer module 53 is further specifically used to: start a supplementary reporting timer, wherein the supplementary reporting timer is used to periodically obtain and report the connection status.

[0100] Optionally, in some embodiments, the reporting module 54 is further specifically used to: determine that the length of the memory variable is equal to or greater than a preset reporting number, take out the buffered abnormal status codes from the memory variable in sequence, and report them; determine that the length of the memory variable is less than the preset reporting number, and end the abnormal status reporting of the memory variable; confirm that the cache file is not empty, take out the buffered abnormal status codes one by one from the cache file in sequence, and report them; confirm that the reporting is complete, and clear the abnormal status codes that have been reported in the memory variable and the cache file.

[0101] Since the embodiments of the device part correspond to the embodiments of the above-mentioned method, please refer to the above-mentioned method embodiment for the introduction of the abnormal reporting device 50 of the Internet of Things device provided in the embodiment of the present invention. The embodiment of the present invention will not be repeated here, and it has the same beneficial effects as the abnormal reporting method of the above-mentioned Internet of Things device.

[0102] See also Figure 6 , Figure 6 It is a structural diagram of an embodiment of the storage medium provided by the present application.

[0103] The storage medium 60 stores program data 61. When the program data 61 is executed by the processor, the following is achieved: Figures 1 to 4 The described method for reporting abnormalities of IoT devices.

[0104] The program data 61 is stored in a storage medium 60, and includes a number of instructions for enabling a network device (such as a router, a personal computer, a server, or other network device) or a processor to execute all or part of the steps of the methods of the various embodiments of the present application.

[0105] Optionally, the storage medium 60 may be a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, an optical disk, or other medium that can store the program data 61 .

[0106] See also Figure 7 , Figure 7 It is a structural schematic diagram of an embodiment of a computer device provided by the present application.

[0107] The computer device 70 includes a processor 72 and a memory 71 connected to each other. The memory 71 stores a computer program. When the processor 72 executes the computer program, the following is achieved: Figures 1 to 4 The described abnormality reporting method of the Internet of Things device. The memory 71 may include the storage medium 60, or may be other independently developed memory.

[0108] Different from the prior art, the present application discloses an abnormality reporting method, device, medium and device for IoT devices. By identifying the abnormal state reflected by the abnormal state log through a digital sequence, the abnormal state code is obtained, which can greatly reduce the consumption of log data on the device operating performance and the storage space occupied by the IoT device, and reduce the amount of data required for abnormal reporting and processing. Buffering or reporting according to the reported connection state can provide a certain buffering effect for the reporting of the abnormal state, retain the integrity of the abnormal state information as much as possible, realize timely and rapid abnormal reporting, reduce the occurrence of underreporting, improve the efficiency of abnormal handling, reduce the corresponding cost and performance consumption, and can quickly analyze remotely, speed up the location and repair efficiency of faults, which is conducive to improving troubleshooting efficiency, and provides a data basis for early warning and predictive maintenance of equipment failures, which can effectively ensure the smoothness and stability of related business operations.

[0109] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, medium embodiment and equipment embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0110] The present application can be used in many general or special computing system environments or configurations, such as personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed methods, devices, storage media, and computer equipment can be implemented in other ways. For example, the device implementation described above is only illustrative, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0112] The above are merely embodiments of the present application and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for reporting abnormalities of an Internet of Things device, characterized in that: include: Obtain abnormal status logs of IoT devices; Encoding the abnormal state log based on a preset encoding rule to identify the corresponding abnormal state with a digital sequence to obtain an abnormal state code; Determine that the reported connection state is an unavailable state, and buffer the abnormal state code; Determine that the reported connection state is an available state, report the buffered abnormal state code, and / or report the real-time abnormal state code.

2. The abnormality reporting method of the Internet of Things device according to claim 1 is characterized in that: The encoding of the abnormal state log based on a preset encoding rule to identify the corresponding abnormal state with a preset digital sequence to obtain the abnormal state code includes: Extracting device information, function status information, and associated information of the function status information from the abnormal status log; Identify the device information based on the device identification code; Obtaining a state identification code corresponding to the functional state information from a preset state meaning comparison table, so as to identify the functional state information with the state identification code; Converting the associated information into an associated information code in a preset standard digital sequence format, so as to identify the associated information with the associated information code; The abnormal state code is obtained based on the device identification code, the state identification code and the associated information code.

3. The abnormality reporting method of the Internet of Things device according to claim 2 is characterized in that: The associated information includes at least one of a user identity card identification code, an appearance time of the functional status information, and an abnormal value corresponding to the functional status information.

4. The abnormality reporting method of the Internet of Things device according to claim 1 is characterized in that: The step of determining that the reported connection state is an unavailable state and buffering the abnormal state code comprises: Determining that a memory variable is not full, and storing the abnormal state code in the memory variable; Determining that the memory variable is full and determining that the cache file is not full, and storing the abnormal state code in the cache file; Determine that the memory variable and the cache file are full, and discard the abnormal state code.

5. The abnormality reporting method of the Internet of Things device according to claim 4 is characterized in that: The determining that the reported connection state is an available state, reporting the buffered abnormal state code, and / or reporting the real-time abnormal state code includes: Determine that the length of the memory variable is equal to or greater than a preset reporting number, take out the buffered abnormal status codes from the memory variable in sequence, and report them; Determining that the length of the memory variable is less than a preset reporting number, and ending the abnormal state reporting of the memory variable; Confirm that the cache file is not empty, take out the buffered abnormal status codes one by one from the cache file in sequence, and report them; Confirm that the reporting is completed, and clear the abnormal status code that has been reported in the memory variable and the cache file.

6. The abnormality reporting method of the Internet of Things device according to claim 1 is characterized in that: The method further comprises: determining that the reported connection state is an unavailable state, buffering the abnormal state code, and determining that the reported connection state is an available state, reporting the buffered abnormal state code, and / or reporting the real-time abnormal state code before: A supplementary reporting timer is started, wherein the supplementary reporting timer is used to periodically obtain the reporting connection status.

7. The abnormality reporting method of the Internet of Things device according to claim 1 is characterized in that: The abnormal status log includes at least one of an error return value exception, a no result return value exception, a large fluctuation exception, and a state mutation exception.

8. An abnormality reporting device for an Internet of Things device, characterized in that: include: The acquisition module is used to obtain the abnormal status log of the IoT device; An encoding module, used for encoding the abnormal state log based on a preset encoding rule, so as to identify the corresponding abnormal state with a digital sequence, and obtain an abnormal state code; A buffer module, used to determine that the reported connection state is an unavailable state, and buffer the abnormal state code; The reporting module is used to determine that the reporting connection state is an available state, report the buffered abnormal state code, and / or report the real-time abnormal state code.

9. A storage medium having program data stored thereon, characterized in that: When the program data is executed by the processor, the steps of the abnormality reporting method of the Internet of Things device as described in any one of claims 1 to 7 are implemented.

10. A computer device, characterized in that: It includes a processor and a memory connected to each other, the memory stores a computer program, and when the processor executes the computer program, the steps of the abnormality reporting method of the Internet of Things device as described in any one of claims 1 to 7 are implemented.

Images