IoT device status processing methods, devices and computer equipment

Abstract

This application provides a method, apparatus, and computer device for processing the status of IoT devices. The method includes: when an offline device is detected among non-directly connected devices, generating offline pseudo-operating condition data for the offline device and sending the offline pseudo-operating condition data to a message queue; when operating condition data of a non-directly connected device is collected, sending the operating condition data of the non-directly connected device to the message queue; when reading the offline pseudo-operating condition data from the message queue, determining the operating status of the non-directly connected device based on the offline pseudo-operating condition data; when reading the operating condition data from the message queue, adding an online status attribute to the operating condition data to obtain corrected operating condition data, and determining the operating status of the non-directly connected device based on the corrected operating condition data. In this way, the operating status of IoT devices can be determined through online / offline pseudo-operating condition data, supporting real-time calculation of the operating status of IoT devices and reducing the cost of IoT platforms.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus and computer device for processing the status of an Internet of Things (IoT) device. Background Technology

[0002] In existing Internet of Things (IoT) systems, the online / offline status detection program and the operational status processing program for IoT devices are separate. The online / offline status data of IoT devices is separate from the operational status data uploaded by the devices. This means that the online / offline status processing cannot reuse the stream processing platform capabilities of the operational status processing program. Instead, it relies on periodically running calculation scripts to retrieve online / offline status and operational status data from the database to calculate related attributes. The output of these attributes depends on the online / offline status detection program and the operational status processing program. Due to the latency of these programs, the relevant attributes cannot be presented in real time, nor can real-time alarms for online / offline status related attributes be provided. In summary, existing IoT systems suffer from low real-time processing performance for IoT device online / offline status and operational status data. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a method, apparatus, and computer device for processing the status of Internet of Things (IoT) devices.

[0004] In a first aspect, embodiments of this application provide a state processing method for an Internet of Things (IoT) device, the method comprising:

[0005] When an offline device is detected among the non-directly connected devices, offline pseudo-operating condition data of the offline device is generated and sent to the message queue.

[0006] When operating condition data of non-directly connected devices is collected, the operating condition data of the non-directly connected devices is sent to the message queue.

[0007] When reading the offline pseudo-operating condition data from the message queue, the working status of the non-directly connected device is determined based on the offline pseudo-operating condition data.

[0008] When the operating condition data is read from the message queue, an online status attribute is added to the operating condition data to obtain corrected operating condition data, and the operating status of the non-directly connected device is determined based on the corrected operating condition data.

[0009] Secondly, embodiments of this application provide a state processing apparatus for an Internet of Things (IoT) device, the apparatus comprising:

[0010] The generation module is used to generate offline pseudo-operating condition data of the offline device when an offline device is detected among the non-directly connected devices, and send the offline pseudo-operating condition data of the offline device to the message queue.

[0011] The sending module is used to send the operating condition data of the non-directly connected device to the message queue when the operating condition data of the non-directly connected device is collected.

[0012] The first determining module is used to determine the working status of the non-directly connected device based on the offline pseudo-working condition data when reading the offline pseudo-working condition data from the message queue.

[0013] The second determining module is used to add an online status attribute to the operating condition data when reading the operating condition data from the message queue to obtain corrected operating condition data, and to determine the operating status of the non-directly connected device based on the corrected operating condition data.

[0014] Thirdly, embodiments of this application provide a computer device, including a memory and a processor, wherein the memory is used to store a computer program, and the computer program executes the state processing method for an Internet of Things device provided in the first aspect when the processor is running.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a processor, executes the state processing method for an Internet of Things device provided in the first aspect.

[0016] The IoT device status processing method, apparatus, and computer equipment provided in this application, when detecting an offline device among non-directly connected devices, generate offline pseudo-operating condition data for the offline device and send the offline pseudo-operating condition data to a message queue; when collecting operating condition data of a non-directly connected device, send the operating condition data of the non-directly connected device to the message queue; when reading the offline pseudo-operating condition data from the message queue, determine the working status of the non-directly connected device based on the offline pseudo-operating condition data; when reading the operating condition data from the message queue, add an online status attribute to the operating condition data to obtain corrected operating condition data, and determine the working status of the non-directly connected device based on the corrected operating condition data. In this way, the offline pseudo-operating condition data and corrected operating condition data of non-directly connected devices can determine the working status of non-directly connected devices, support real-time calculation of the working status of non-directly connected devices, reduce the cost of the IoT platform, and improve the real-time performance of IoT device operating condition data processing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be considered as a limitation on the scope of protection of this application. In the various drawings, similar components are numbered similarly.

[0018] Figure 1 A flowchart illustrating a state processing method for an IoT device provided in an embodiment of this application is shown.

[0019] Figure 2 This paper illustrates another flowchart of the IoT device state processing method provided in an embodiment of this application;

[0020] Figure 3 A schematic diagram of the state processing apparatus for an Internet of Things (IoT) device provided in an embodiment of this application is shown.

[0021] Figure 4 A schematic diagram of the structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0022] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0023] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0024] In the following, the terms “comprising,” “having,” and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as excluding, firstly, the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more features, numbers, steps, operations, elements, components, or combinations thereof.

[0025] Furthermore, the terms "first," "second," and "third" are used only to distinguish descriptions and should not be interpreted as indicating or implying relative importance.

[0026] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0027] Example 1

[0028] This disclosure provides a method for handling the state of an Internet of Things (IoT) device.

[0029] For details, see Figure 1 The status handling methods for IoT devices include:

[0030] Step S101: When an offline device is detected among the non-directly connected devices, offline pseudo-operating condition data of the offline device is generated and sent to the message queue.

[0031] In this embodiment, IoT devices include non-directly connected devices and directly connected devices. IoT devices that connect to the Internet through a gateway with Internet access capabilities are called non-directly connected devices; IoT devices with Internet access capabilities are called directly connected devices.

[0032] It should be noted that the offline status of an IoT device can be determined based on the number of records kept on non-directly connected devices and the offline detection period for these devices. When a non-directly connected device keeps records, it is considered online. If a non-directly connected device does not keep records and the period of non-keeping records exceeds the offline detection period, it is considered offline.

[0033] The IoT device status processing method provided in this embodiment can be applied to computer devices. The computer devices can be equipped with operating condition processing programs, online / offline status detection programs, data acquisition modules, offline detection modules for non-directly connected devices, real-time processing modules, message queues, online status add-ons, etc., to execute the steps of the IoT device status processing method.

[0034] In this embodiment, the data acquisition module collects operating condition data from non-directly connected devices and writes the collected data into a message queue. The offline detection module for non-directly connected devices obtains their offline records. The offline status detector for non-directly connected devices determines whether a device is offline by recording the device's uptime and offline detection cycle. When a non-directly connected device is uptime, it is considered online. If a non-directly connected device is not uptime and the uptime exceeds the offline detection cycle of the IoT device, it is considered offline. If a non-directly connected device is offline, pseudo-offline operating condition data is generated.

[0035] Step S102: When the operating condition data of the non-directly connected device is collected, the operating condition data of the non-directly connected device is sent to the message queue.

[0036] In this embodiment, the data acquisition module collects the operating condition data of the non-directly connected devices, and sends the collected operating condition data of the non-directly connected devices to the message queue for storage.

[0037] Step S103: When reading the offline pseudo-operating condition data from the message queue, determine the working status of the non-directly connected device based on the offline pseudo-operating condition data;

[0038] In this embodiment, the real-time processing module calculates the value of the work status attribute based on offline pseudo-working condition data and preset calculation rules. The work status attribute values ​​include offline, stopped, standby, and working. The preset calculation rule can be (OnWorkThreshold = 100, OffWorkThreshold = 50).

[0039] For example, the main code for implementing step S103 is as follows:

[0040] if(__online__){

[0041] def maxL = $max(Ia, Ib, Ic);

[0042] if(maxL>=OnWorkThreshold)then return "job";

[0043] else if (maxL > OffWorkThreshold) "Standby";

[0044] else "shutdown";

[0045] else "offline";

[0046] In this embodiment, the working status of non-directly connected devices can also be sent to the database for processing such as data entry; no restrictions are imposed here.

[0047] In this way, the IoT platform can treat offline status attributes as operational status attributes, supporting real-time calculation of offline status-related attributes and determination of operational status, and can display the online / offline status of devices in real time. This provides a data foundation for subsequent online / offline rate calculations.

[0048] Step S104: When reading the operating condition data from the message queue, add an online status attribute to the operating condition data to obtain corrected operating condition data, and determine the operating status of the non-directly connected device based on the corrected operating condition data.

[0049] In this embodiment, the online status attacher obtains the operating condition data collected by the data acquisition module from the message queue, and attaches the online status attribute (true) of non-directly connected devices to the operating condition data to generate corrected operating condition data. This ensures that all operating condition data processed by the cloud platform includes the online / offline status attribute. The online status attacher works in conjunction with the real-time processing module.

[0050] It should be noted that the data acquisition module generally does not parse the operating condition data, but mainly forwards it. The real-time processing module does parse the operating condition data. Therefore, placing the online status add-on in the real-time processing module has minimal impact on the original operating condition processing system.

[0051] For example, if the main information of the operating condition data is as follows:

[0052] {"cts":xxxxx,

[0053] "__properties__":{"la":101,"lb":102,"lc":103}

[0054] }

[0055] After processing in step S104, the main information of the corrected operating condition data is as follows:

[0056] {"cts":xxxxx,

[0057] "__properties__":{"la":101,"lb":102,"lc":103,"__online__":true}

[0058] }

[0059] For example, if the main information of the operating condition data is as follows:

[0060] {

[0061] "cts":1630365662653,

[0062] "__properties__":{

[0063] "t":200,

[0064] "r":1000

[0065] }

[0066] }

[0067] After processing in step S104, the main information of the corrected operating condition data is as follows:

[0068] {

[0069] "cts":1630365662653,

[0070] "__properties__":{

[0071] "t":200,

[0072] "r":1000,

[0073] "__online__":true

[0074] }

[0075] }

[0076] In this embodiment, the working state of the non-directly connected equipment can be calculated using preset calculation rules, which can be (OnWorkThreshold = 100, OffWorkThreshold = 50). For example, the main code for determining the working state of the non-directly connected equipment based on the corrected working condition data is as follows:

[0077] if(__online__){

[0078] def maxL = $max(Ia, Ib, Ic);

[0079] if(maxL>=OnWorkThreshold)then return "job";

[0080] else if (maxL > OffWorkThreshold) "Standby";

[0081] else "shutdown";

[0082] else "offline";

[0083] In this way, the IoT platform can treat online status attributes as operational status attributes, supporting real-time processing of online status-related attribute calculations and operational status determination, and enabling real-time display of device online status. This provides a data foundation for subsequent online / offline rate calculations.

[0084] In summary, steps S101 to S104 involve simulating the offline status of detected devices by sending a pseudo-offline status message to the message queue. Simultaneously, an online status appender is added to the real-time processing module. For the device-uploaded status data, the network status (value: online) attribute is appended to the status data, ensuring that all status data processed by the cloud platform includes online / offline status attributes. This allows online / offline status attributes to be treated like regular status attributes, participating in attribute calculations and rule triggering, thus improving real-time processing efficiency.

[0085] Please see Figure 2 The status handling method for IoT devices may also include the following steps:

[0086] Step S105: When the online / offline status of the directly connected device is collected, pseudo-operating condition data for online / offline status is generated based on the online / offline status of the directly connected device, and the pseudo-operating condition data for online / offline status is sent to the message queue.

[0087] For directly connected devices, after obtaining the online / offline status of the directly connected devices by subscribing to connection status messages from an IoT MQTT broker (such as EMQ), pseudo-online / offline status data can also be simulated and generated. This pseudo-online / offline status data can further include both online and offline pseudo-offline status data. In this embodiment, after constructing the pseudo-online / offline status attribute data, the pseudo-online / offline status data is sent to the message queue.

[0088] Step S106: When reading the online / offline pseudo-operating condition data from the message queue, determine the operating status of the directly connected device based on the online / offline pseudo-operating condition data.

[0089] In this way, the real-time processing capabilities of the IoT platform can be reused for directly connected devices to process the calculation of the up and down status related attributes of the directly connected devices in real time, and / or trigger alarm messages to generate and perform alarm operations according to rules.

[0090] For example, the main information in the pseudo-operating condition data of directly connected equipment is as follows:

[0091] {

[0092] "cts":1630365672653,

[0093] "__properties__":{

[0094] "__online__":true

[0095] }

[0096] }

[0097] For offline pseudo-operating condition data, the main information is as follows:

[0098] {

[0099] "cts":1630365672654,

[0100] "__properties__":{

[0101] "__online__":false

[0102] }

[0103] }

[0104] In this embodiment, the step of detecting whether a non-directly connected device is an offline device includes:

[0105] Get the current time;

[0106] Determine the offline time of each offline record from the offline record queue of non-directly connected devices, and determine whether the offline time of each offline record is less than or equal to the current time;

[0107] Identify multiple first offline records among the offline records whose offline time is less than or equal to the current time;

[0108] The device identifiers of each of the first offline records are obtained sequentially in ascending order of offline time.

[0109] Obtain the latest offline record corresponding to each device identifier from the pre-acquired latest offline data set of devices;

[0110] Determine whether there exists a target offline record in each of the first offline records that is identical to the corresponding most recent offline record;

[0111] If the target offline record exists, then the non-directly connected device corresponding to the target device identifier in the target offline record is determined to be an offline device.

[0112] In this embodiment, by setting up separate offline record queues and the latest offline data set for each device, frequent deletion and insertion of data in the sorted offline record queue can be effectively avoided. Offline records include device identifier (deviceId), uptime (cts), and offline time (offlineTime). The offline record queue is sorted by offline time.

[0113] For example, the main information for offline operation is as follows:

[0114] {

[0115] "cts":1630365662653,

[0116] "__properties__":{

[0117] "__online__":false

[0118] }

[0119] }

[0120] In the above key information, cts represents the uptime, which is of type long; __properties__ represents a collection of properties, which is of type JSON object; and __online__ represents the online / offline status property, which is of type boolean, where true indicates online and false indicates offline.

[0121] In this embodiment, before determining the offline time of each offline record from the offline record queue of the non-directly connected device, the method further includes:

[0122] Collect operating data from multiple non-directly connected devices;

[0123] The offline time of each non-directly connected device is determined based on the offline inspection cycle and the operating condition data of each non-directly connected device.

[0124] The offline records of each IoT device are written into the offline record queue and the latest offline data set of each device according to the offline time of each non-directly connected device.

[0125] In this embodiment, the offline record queue is sorted in ascending order of the offline time of non-directly connected devices.

[0126] Additionally, the offline time of non-directly connected devices can be calculated using the following formula 1:

[0127] Formula 1: offlineTime=cts+offlineCheckPeriod;

[0128] Where offlineTime represents offline time, cts represents online time, and offlineCheckPeriod represents offline detection period.

[0129] Using red-black trees to sort offline records effectively avoids frequent deletions and insertions in the sorting queue, improving the efficiency of offline detection for non-directly connected devices.

[0130] For example, the main information in the operating condition data is as follows:

[0131] {

[0132] "cts":1630365662653,

[0133] "__properties__":{

[0134] "t":200,

[0135] “r”:1000

[0136] }

[0137] }

[0138] In this embodiment, after determining whether the offline time of each offline record is less than or equal to the current time, the method further includes:

[0139] If there is a second offline record among the offline records whose offline time is greater than the current time, then the waiting time until the next offline detection is determined;

[0140] Determine whether the waiting time is greater than zero;

[0141] If the waiting time is greater than zero, then after the waiting time has elapsed, the step of obtaining the current time is repeated.

[0142] If the waiting time is zero, then the step of obtaining the current time is executed again.

[0143] In this embodiment, after writing the offline records of each IoT device into the offline record queue according to the offline time of each non-directly connected device, the method further includes:

[0144] The offline records in the offline record queue are sorted using a red-black tree algorithm.

[0145] In this embodiment, the offline records in the offline record queue are sorted by a red-black tree algorithm. The offline record queue is sorted in ascending order of the offline time of non-directly connected devices, which improves the efficiency of subsequent data processing based on the offline record queue.

[0146] In this embodiment, the method further includes:

[0147] Alarm messages are generated based on the operating status of non-directly connected or directly connected devices.

[0148] In this embodiment, alarm messages can be generated by combining alarm rules. The alarm rules can be whenworkStatus == "offline" && $lastStatet(workStatus) == "job", or other types of alarm rules, which are not limited here.

[0149] In this way, by sending offline pseudo-operating conditions and attaching online status attributes to the operating condition data, the operating status of IoT devices can be generated, alarm messages can be generated based on the operating status, alarm triggering can be supported, and alarm efficiency can be improved.

[0150] The IoT device status processing method provided in this embodiment generates offline pseudo-operating condition data for the offline device when an offline device is detected among non-directly connected devices, and sends the offline pseudo-operating condition data to a message queue. When operating condition data of a non-directly connected device is collected, the operating condition data of the non-directly connected device is sent to the message queue. When the offline pseudo-operating condition data is read from the message queue, the working status of the non-directly connected device is determined based on the offline pseudo-operating condition data. When the operating condition data is read from the message queue, an online status attribute is added to the operating condition data to obtain corrected operating condition data, and the working status of the non-directly connected device is determined based on the corrected operating condition data. In this way, the offline pseudo-operating condition data and corrected operating condition data of non-directly connected devices can determine the working status of non-directly connected devices, support real-time calculation of the working status of non-directly connected devices, reduce the cost of IoT platforms, and improve the real-time performance of IoT device operating condition data processing. In addition, when the IoT platform service needs to be upgraded or shut down, devices can be taken offline in advance by sending online / offline pseudo-operating condition data to prevent the loss or delay of offline events.

[0151] Example 2

[0152] Furthermore, embodiments of this disclosure provide a state processing apparatus for an Internet of Things (IoT) device.

[0153] Specifically, such as Figure 3 As shown, the IoT device status processing unit 300 includes:

[0154] The generation module 301 is used to generate offline pseudo-operating condition data of the offline device when an offline device is detected in the non-directly connected device, and send the offline pseudo-operating condition data of the offline device to the message queue.

[0155] The sending module 302 is used to send the operating condition data of the non-directly connected device to the message queue when the operating condition data of the non-directly connected device is collected.

[0156] The first determining module 303 is used to determine the working status of the non-directly connected device based on the offline pseudo-working condition data when reading the offline pseudo-working condition data from the message queue.

[0157] The second determining module 304 is used to add an online status attribute to the operating condition data when reading the operating condition data from the message queue to obtain corrected operating condition data, and to determine the operating status of the non-directly connected device based on the corrected operating condition data.

[0158] In this embodiment, the state processing device of the Internet of Things device further includes:

[0159] The first processing module is used to generate pseudo-operating condition data based on the online / offline status of the directly connected device when the online / offline status of the directly connected device is collected, and to send the pseudo-operating condition data to the message queue.

[0160] The third determining module is used to determine the working status of the directly connected device based on the online / offline pseudo-operating condition data when reading the online / offline pseudo-operating condition data from the message queue.

[0161] In this embodiment, the state processing device of the Internet of Things device further includes:

[0162] The second processing module is used to obtain the current time;

[0163] Determine the offline time of each offline record from the offline record queue of non-directly connected devices, and determine whether the offline time of each offline record is less than or equal to the current time;

[0164] Identify multiple first offline records among the offline records whose offline time is less than or equal to the current time;

[0165] The device identifiers of each of the first offline records are obtained sequentially in ascending order of offline time.

[0166] Obtain the latest offline record corresponding to each device identifier from the pre-acquired latest offline data set of devices;

[0167] Determine whether there exists a target offline record in each of the first offline records that is identical to the corresponding most recent offline record;

[0168] If the target offline record exists, then the non-directly connected device corresponding to the target device identifier in the target offline record is determined to be an offline device.

[0169] In this embodiment, the state processing device 300 of the Internet of Things device further includes:

[0170] The data acquisition module is used to collect operating data from multiple non-directly connected devices.

[0171] The offline time of each non-directly connected device is determined based on the offline inspection cycle and the operating condition data of each non-directly connected device.

[0172] The offline records of each IoT device are written into the offline record queue and the latest offline data set of each device according to the offline time of each non-directly connected device.

[0173] In this embodiment, the state processing device of the Internet of Things device further includes:

[0174] The execution module is used to determine the waiting time until the next offline detection if there is a second offline record among the offline records whose offline time is greater than the current time;

[0175] Determine whether the waiting time is greater than zero;

[0176] If the waiting time is greater than zero, then after the waiting time has elapsed, the step of obtaining the current time is repeated.

[0177] If the waiting time is zero, then the step of obtaining the current time is executed again.

[0178] In this embodiment, the state processing device of the Internet of Things device further includes:

[0179] The sorting module is used to sort the offline records in the offline record queue using a red-black tree algorithm.

[0180] In this embodiment, the state processing device of the Internet of Things device further includes:

[0181] An alarm module is used to generate alarm messages based on the working status of the IoT device.

[0182] This embodiment provides an IoT device state processing device 300 that can be used for the IoT device state processing method provided in Embodiment 1. To avoid repetition, it will not be described again here.

[0183] The IoT device status processing device provided in this embodiment generates offline pseudo-operating condition data for the offline device when an offline device is detected among non-directly connected devices, and sends the offline pseudo-operating condition data to a message queue. When operating condition data of a non-directly connected device is collected, the operating condition data of the non-directly connected device is sent to the message queue. When the offline pseudo-operating condition data is read from the message queue, the working status of the non-directly connected device is determined based on the offline pseudo-operating condition data. When the operating condition data is read from the message queue, an online status attribute is added to the operating condition data to obtain corrected operating condition data, and the working status of the non-directly connected device is determined based on the corrected operating condition data. In this way, the offline pseudo-operating condition data and corrected operating condition data of non-directly connected devices can determine the working status of non-directly connected devices, support real-time calculation of the working status of non-directly connected devices, reduce the cost of the IoT platform, and improve the real-time performance of IoT device operating condition data processing. In addition, when the IoT platform service needs to be upgraded or shut down, devices can be taken offline in advance by sending online / offline pseudo-operating condition data to prevent the loss or delay of offline events.

[0184] Example 3

[0185] Furthermore, this disclosure provides a computer device including a memory and a processor. The memory stores a computer program, which, when run on the processor, executes the state processing method for an IoT device provided in the above-described method embodiment 1.

[0186] The computer device 400 includes: a transceiver 401, a bus interface, and a processor 402. The processor 402 is used to: when an offline device is detected in a non-directly connected device, generate offline pseudo-operating condition data of the offline device and send the offline pseudo-operating condition data of the offline device to a message queue.

[0187] When operating condition data of non-directly connected devices is collected, the operating condition data of the non-directly connected devices is sent to the message queue.

[0188] When reading the offline pseudo-operating condition data from the message queue, the working status of the non-directly connected device is determined based on the offline pseudo-operating condition data.

[0189] When the operating condition data is read from the message queue, an online status attribute is added to the operating condition data to obtain corrected operating condition data, and the operating status of the non-directly connected device is determined based on the corrected operating condition data.

[0190] In this embodiment, the processor 402 is further configured to: when the online / offline status of a directly connected device is collected, generate pseudo-online / offline status data based on the online / offline status of the directly connected device, and send the pseudo-online / offline status data to the message queue;

[0191] When reading the online / offline pseudo-operating condition data from the message queue, the operating status of the directly connected device is determined based on the online / offline pseudo-operating condition data.

[0192] In this embodiment, the processor 402 is further configured to: obtain the current time;

[0193] Determine the offline time of each offline record from the offline record queue of non-directly connected devices, and determine whether the offline time of each offline record is less than or equal to the current time;

[0194] Identify multiple first offline records among the offline records whose offline time is less than or equal to the current time;

[0195] The device identifiers of each of the first offline records are obtained sequentially in ascending order of offline time.

[0196] Obtain the latest offline record corresponding to each device identifier from the pre-acquired latest offline data set of devices;

[0197] Determine whether there exists a target offline record in each of the first offline records that is identical to the corresponding most recent offline record;

[0198] If the target offline record exists, then the non-directly connected device corresponding to the target device identifier in the target offline record is determined to be an offline device.

[0199] In this embodiment, the processor 402 is further configured to: collect operating condition data from multiple non-directly connected devices;

[0200] The offline time of each non-directly connected device is determined based on the offline inspection cycle and the operating condition data of each non-directly connected device.

[0201] The offline records of each IoT device are written into the offline record queue and the latest offline data set of each device according to the offline time of each non-directly connected device.

[0202] In this embodiment, the processor 402 is further configured to: if there is a second offline record in each offline record whose offline time is greater than the current time, then determine the waiting time until the next offline detection;

[0203] Determine whether the waiting time is greater than zero;

[0204] If the waiting time is greater than zero, then after the waiting time has elapsed, the step of obtaining the current time is repeated.

[0205] If the waiting time is zero, then the step of obtaining the current time is executed again.

[0206] In this embodiment, the processor 402 is further configured to: sort the offline records of the offline record queue using a red-black tree algorithm.

[0207] In this embodiment, the processor 402 is further configured to: generate alarm messages based on the operating status of non-directly connected devices or directly connected devices.

[0208] In this embodiment, the computer device 400 further includes a memory 403. Figure 4 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 402) and memory (memory 403). The bus architecture can also link together various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 401 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. The processor 402 is responsible for managing the bus architecture and general processing, and the memory 403 can store data used by the processor 402 during operation.

[0209] The computer device 400 provided in this embodiment of the invention can execute the steps of the IoT device state processing method in the previous embodiment 1, which will not be repeated here.

[0210] Example 4

[0211] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the state processing method for the Internet of Things device provided in Embodiment 1.

[0212] In this embodiment, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0213] The computer-readable storage medium provided in this embodiment can be the state processing method of the Internet of Things device provided in Embodiment 1. To avoid repetition, it will not be described again here.

[0214] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0215] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0216] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for handling the state of an Internet of Things (IoT) device, characterized in that, The method includes: When an offline device is detected among the non-directly connected devices, offline pseudo-operating condition data of the offline device is generated, and the offline pseudo-operating condition data of the offline device is sent to the message queue. The steps for detecting whether a non-directly connected device is an offline device include: obtaining the current time; collecting operating condition data of multiple non-directly connected devices; determining the offline time of each non-directly connected device according to the offline check cycle and the operating condition data of each non-directly connected device; writing the offline records of each IoT device into the offline record queue and the latest offline data set of the device according to the offline time of each non-directly connected device; determining the offline time of each offline record from the offline record queue of the non-directly connected devices, and judging whether the offline time of each offline record is less than or equal to the current time; determining multiple first offline records in each offline record whose offline time is less than or equal to the current time; sequentially obtaining the device identifier of each first offline record in ascending order of offline time; obtaining the latest offline record corresponding to each device identifier from the pre-obtained latest offline data set of the device; judging whether there is a target offline record in each first offline record that is the same as the corresponding latest offline record; if the target offline record exists, determining that the non-directly connected device corresponding to the target device identifier in the target offline record is an offline device. When operating condition data of non-directly connected devices is collected, the operating condition data of the non-directly connected devices is sent to the message queue. When reading the offline pseudo-operating condition data from the message queue, the working status of the non-directly connected device is determined based on the offline pseudo-operating condition data. When the operating condition data is read from the message queue, an online status attribute is added to the operating condition data to obtain corrected operating condition data, and the operating status of the non-directly connected device is determined based on the corrected operating condition data.

2. The method according to claim 1, characterized in that, The method further includes: When the online / offline status of a directly connected device is collected, pseudo-operating condition data for online / offline status is generated based on the online / offline status of the directly connected device, and the pseudo-operating condition data for online / offline status is sent to the message queue. When reading the online / offline pseudo-operating condition data from the message queue, the operating status of the directly connected device is determined based on the online / offline pseudo-operating condition data.

3. The method according to claim 1, characterized in that, After determining whether the offline time of each offline record is less than or equal to the current time, the method further includes: If there is a second offline record among the offline records whose offline time is greater than the current time, then the waiting time until the next offline detection is determined; Determine whether the waiting time is greater than zero; If the waiting time is greater than zero, then after the waiting time has elapsed, the step of obtaining the current time is repeated. If the waiting time is zero, then the step of obtaining the current time is executed again.

4. The method according to claim 1, characterized in that, After writing the offline records of each IoT device into the offline record queue according to the offline time of each non-directly connected device, the method includes: The offline records in the offline record queue are sorted using a red-black tree algorithm.

5. The method according to claim 2, characterized in that, The method further includes: Alarm messages are generated based on the operating status of non-directly connected or directly connected devices.

6. A state processing device for an Internet of Things (IoT) device, characterized in that, The device includes: The generation module is used to generate offline pseudo-operating condition data of the offline device when an offline device is detected in the non-directly connected device, and send the offline pseudo-operating condition data of the offline device to the message queue. The sending module is used to send the operating condition data of the non-directly connected device to the message queue when the operating condition data of the non-directly connected device is collected. The first determining module is used to determine the working status of the non-directly connected device based on the offline pseudo-working condition data when reading the offline pseudo-working condition data from the message queue. The second determining module is used to add an online status attribute to the operating condition data when reading the operating condition data from the message queue to obtain corrected operating condition data, and to determine the operating status of the non-directly connected device based on the corrected operating condition data. The generation module includes: The second processing module is used to: obtain the current time; determine the offline time of each offline record from the offline record queue of non-directly connected devices; determine whether the offline time of each offline record is less than or equal to the current time; determine multiple first offline records in each offline record whose offline time is less than or equal to the current time; obtain the device identifier of each first offline record in ascending order of offline time; obtain the latest offline record corresponding to each device identifier from the pre-obtained latest offline data set of devices; determine whether there is a target offline record in each first offline record that is the same as the corresponding latest offline record; if the target offline record exists, determine that the non-directly connected device corresponding to the target device identifier in the target offline record is an offline device; The data acquisition module is used to collect operating condition data from multiple non-directly connected devices; determine the offline time of each non-directly connected device based on the offline inspection cycle and the operating condition data of each non-directly connected device; and write the offline records of each IoT device into the offline record queue and the latest offline data set of the device according to the offline time of each non-directly connected device.

7. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program that executes the state processing method of any one of claims 1 to 5 when the processor is running.

8. A computer-readable storage medium, characterized in that, It stores a computer program that, when run on a processor, executes the state processing method for the Internet of Things device according to any one of claims 1 to 5.

Images