Determining HVAC Cycle Type Through Remote Web-Connected Sensor Data

Abstract

Systems and methods are described for identifying and classifying airflow system types. The system may include: (1) an airflow system configured to receive air via a return air pathway and supply air via a supply air pathway; (2) a first sensor disposed proximate to the supply air pathway of the airflow system to collect supply airflow data; (3) a second sensor disposed proximate to the return air pathway of the airflow system to collect return airflow data; and (4) an electronic device including one or more processors communicatively coupled to a memory storing one or more instructions that cause the one or more processors to: (a) receive airflow system data; (b) analyze the airflow system data to generate airflow system cycle data; and (c) classify, based on the airflow system cycle data, an airflow cycle type of the airflow cycle facilitated by the airflow system.

Description

FIELD OF THE DISCLOSURE

Systems and methods are disclosed for determining an airflow system cycle type according to remote sensor data.

BACKGROUND

Airflow systems, such as heating, ventilation, and air conditioning (HVAC) systems, prove and/or condition air flow for a variety of properties according to a variety of functionalities. In regulating air flow and performing such functionalities, the HVAC systems operate according to a number of different cycle types. For example, HVAC systems may operate in a cooling mode, a heating mode, a fan mode, etc. However, the capability of HVAC systems to operate properly according to different cycle types may be indicative of different maintenance, repair, or replacement requirements. As such, determining how an HVAC is performing in various different cycle modes and types is important in maintaining, repairing, and/or replacing the airflow system for a particular property.

However, determining the cycle type in which an HVAC system operates and/or characteristics of such is often difficult or unwieldy. For example, conventional techniques rely on a direct connection installed by a professional using particular equipment to a thermostat or other such centralized HVAC regulation system. However, such equipment is time intensive to install, difficult or expensive to acquire, and/or designed for short-term measurements. It can be difficult, then, for a user to accurately and consistently keep track of various operations of an airflow system, leading to problems with maintaining the airflow system.

SUMMARY

In one aspect, a system for identifying and classifying airflow cycle types may be provided. The system may include: (1) an airflow system configured to receive air via a return air pathway and supply air via a supply air pathway; (2) a first sensor disposed proximate to the supply air pathway of the airflow system and configured to, in an airflow cycle facilitated by the airflow system, collect supply airflow data associated with the supply air pathway, wherein the supply airflow data includes at least a supply temperature of the air supplied via the supply air pathway; (3) a second sensor disposed proximate to the return air pathway of the airflow system and configured to, in the airflow cycle facilitated by the airflow system, collect return airflow data associated with the return air pathway, wherein the return airflow data includes at least a return temperature of the air received via the return air pathway; and (4) an electronic device including one or more processors communicatively coupled to a memory storing one or more instructions that, when executed, cause the one or more processors to: (a) receive airflow system data representative of at least the supply airflow data and the return airflow data; (b) analyze the airflow system data to generate airflow system cycle data associated with the airflow cycle and based at least on the supply temperature of the air supplied via the supply air pathway and the return temperature of the air received via the return air pathway; and (c) classify, based on the airflow system cycle data, an airflow cycle type of the airflow cycle facilitated by the airflow system.

In some implementations, the return airflow data further includes at least a static pressure of the air received via the return air pathway and the airflow system cycle data is further generated based on the static pressure of the air received via the return air pathway.

In further implementations, the supply airflow data further includes at least a relative humidity level of the air supplied via the supply air pathway and the airflow system cycle data is further generated based on the humidity level of the air supplied via the supply air pathway.

In still further implementations, the system further comprises a third sensor disposed proximate to the airflow system and configured to collect moisture data associated with the airflow system, including at least a temperature of an area proximate to the airflow system; and the airflow system cycle data is further generated based on the at least the temperature of the area proximate to the airflow system.

In yet still further implementations, the system further comprises a space sensor configured to collect space data associated with an area in which the space sensor is disposed, including at least one of (i) an air temperature associated with the area or (ii) a relative humidity of the area; and the airflow system cycle data is further generated based on the at least one of (i) the air temperature associated with the area or (ii) the relative humidity of the area.

In further implementations, the airflow system cycle data includes at least one of: (i) a rate of change of the supply temperature, (ii) a supply temperature of the air supplied via the supply air pathway relative to outside air conditions, (iii) a return temperature of the air received via the return air pathway relative to outside air conditions, (iv) an airflow pressure fluctuation, (v) a temperature difference between the supply temperature and an return temperature of the air received via the return air pathway, (vi) a trend of the temperature difference over time, or (vii) a relative value of the supply temperature against a predefined threshold.

In still further implementations, the airflow cycle type is a first airflow cycle type of a plurality of airflow cycle types for a plurality of airflow cycles facilitated by the airflow system and the memory further stores instructions that, when executed, cause the one or more processors to: generate a cycle type table representative of the plurality of airflow cycle types; and cause a user device to display the cycle type table to a user.

In still yet further implementations, the system further comprises a hub data aggregation device configured to aggregate at least the supply airflow data and the return airflow data and transmit the airflow system data to the server.

In some such implementations, the hub data aggregation device is configured to perform a preprocessing operation on the supply airflow data and the return airflow data to generate the airflow system data.

In further implementations, the first sensor is a first wireless self-install sensor and the second sensor is a second wireless self-install sensor.

In another aspect, a method for identifying and classifying an airflow cycle type is provided. The method may include: (a) receiving, by one or more processors, airflow system data representative of at least supply airflow data collected by a first sensor disposed proximate to a supply air pathway of an airflow system and return airflow data collected by a second sensor disposed proximate to a return air pathway of the airflow system, wherein: the supply airflow data includes at least a supply temperature of the air supplied via the supply air pathway collected during an airflow cycle facilitated by the airflow system, and the return airflow data includes at least a return temperature of the air received via the return air pathway collected during an airflow cycle facilitated by the airflow system; (b) analyzing, by the one or more processors and based at least on the supply temperature of the air supplied via the supply air pathway and the return temperature of the air received via the return air pathway, the airflow system data to generate system cycle data associated with the airflow cycle; and (c) classifying, by the one or more processors and based on the airflow system cycle data, an airflow cycle type of the airflow cycle facilitated by the airflow system.

This summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Descriptions. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Advantages will become more apparent to those of ordinary skill in the art from the following description of the preferred aspects, which have been shown and described by way of illustration. As will be realized, the present aspects may be capable of other and different aspects, and their details are capable of modification in various respects. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary system that facilitates capturing and/or retrieving airflow system data from one or more sensors associated with a property, as well as determining one or more cycle types for operations of the airflow system based on the captured and/or retrieved airflow system data;

FIG. 2 depicts an exemplary architecture for a hub system to facilitate transfer of airflow system data from one or more sensors to a cloud server;

FIG. 3 depicts an exemplary architecture for an airflow system, hub, and analysis server similar to those depicted with regard to the airflow system of FIG. 1;

FIG. 4A depicts an exemplary user interface displaying a performance of an airflow system similar to the airflow system of FIG. 1;

FIG. 4B depicts an exemplary user interface similar to that of FIG. 4A, but in which the user interface depicts a runtime of the airflow system;

FIG. 4C depicts an exemplary user interface similar to that of FIG. 4A, but in which the user interface depicts details of a particular set of airflow operation cycles;

FIG. 4D depicts an exemplary user interface similar to that of FIG. 4A, but in which the user interface depicts an overall runtime and number of airflow operation cycles in a particular day;

FIG. 5A depicts an graph of measured temperatures according to various sensors as implemented in an airflow system, such as the airflow system of FIG. 1;

FIG. 5B depicts an exemplary table organizing various airflow system metrics and an airflow system cycle type for an airflow system such as the airflow system of FIG. 1; and

FIG. 6 depicts a flow diagram representing an exemplary computer-implemented method for analyzing and classifying an airflow cycle type for an airflow system, such as the airflow system of FIG. 1.

The Figures depict preferred implementations for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative implementations of the systems and methods illustrated herein may be employed without departing from the principles of the invention described herein.

DETAILED DESCRIPTION

Techniques, systems, apparatuses, components, devices, and methods are disclosed for identifying and classifying a cycle type for an airflow system. For example, a system may use a variety of specialized do-it-yourself (DIY) sensors to capture and analyze data related to the airflow in a property and subsequently determine whether the airflow characteristics are indicative of a particular operation mode and/or cycle type at a particular time. As such, the system may classify an airflow system operation and/or cycle type without conventional methods, such as data captured directly from a thermostat using devices with a wired connection to the thermostat.

A system that implements the methods described herein offers multiple benefits over conventional systems. In particular, by using specific sensors as described herein, a system implementing a cycle logic algorithm may collect and analyze particular forms of data useful for making a determination regarding an airflow system cycle type rather than retrieving a direct signal from a thermostat or other such airflow system control apparatus, as conventional techniques would normally require. As such, time and resources are saved by automatically performing such a process and making determinations from data gathered over time rather than requiring a direct connection manually initiated by a professional using particular tools. Moreover, the specialized data used to make the instant determinations enable the systems discussed herein to make determinations that conventional systems would not normally be able to make, as conventional systems generally gather the airflow cycle type directly from an airflow system control apparatus. Further, the system described herein allows for constant monitoring throughout a system lifetime, rather than conventional spot measurement techniques. As such, the instant systems allow for a more holistic view and analysis of a system rather than only short-term instantaneous measurements.

Additionally, a system that implements the methods described herein may specifically collect particular and unique data in the form of supply airway data (e.g., supply air temperature or pressure) from a first sensor and return airway data (e.g., return air temperature or pressure) from a second sensor. By using unique data particularly associated with an airflow system, a system implementing the instant techniques as described herein may analyze data and make determinations that a conventional system would be otherwise unable to make, enabling the system to generate and analyze particular airflow system data (e.g., various cycle variables and/or determined metrics). By using the particular airflow system data, the system may more consistently classify and record an airflow system cycle type than conventional techniques, and may perform such classifications without relying on a manual connection as performed using specialized tools unavailable to most users.

Similarly, the instant techniques may utilize a machine learning model to determine an airflow system cycle type. By using and training such a machine learning model, a system implementing the methods described herein may further represent an improvement upon conventional techniques. In particular, by utilizing the machine learning model in conjunction with the sensor data described herein, systems implementing the instant techniques may offer an improvement over conventional systems by consistently generating determinations with regard to the operation of the airflow system while lowering risk of unnoticed anomalous activity that may result through short-term, temporary measurements according to conventional systems. Further, the machine learning model may improve the determinations made by the system through improving the ability of the system to recognize patterns in data.

FIG. 1 depicts an exemplary system 100 for capturing and/or retrieving airflow system data from one or more sensors associated with a property, as well as classifying the airflow cycle type at various points in time during operation using the captured and/or retrieved data. Depending on the implementation, the system 100 may gather data regarding airflow from one or more sensors in a property. In further implementations, the system 100 may then analyze the gathered data to classify the airflow system cycle type(s) at various points in time.

The system 100 analyzes a property 105 including an airflow system 110. In some implementations, the airflow system 110 may be a heating, ventilation, and air conditioning (HVAC) system. Depending on the implementation, the airflow system 110 may operate in a number of different cycle types (also referred to herein as “operation modes,” “cycle modes,” “operation types,” “modes,” etc.). For example, the airflow system 110 may operate in a cooling mode, a heating mode, a fan mode (e.g., to generate a breeze in a property without significantly cooling or heating the air), etc. In further implementations, the airflow system 110 may operate according to a particular cycle type. In still further implementations, the airflow system 110 may operate according to a particular cycle type for a particular location or portion of a property 105. For example, the airflow system 110 may cool, heat, etc. one room of the property 105 while not operating in the other rooms. Similarly, the airflow system 110 may perform operations according to one cycle type in one area while performing operations according to another cycle type in another area (e.g., operating in the cooling mode in one room and operating in the fan mode in another room).

Further, the property 105 may be any property (e.g., house, apartment complex, office building, etc.) with an airflow system 110 and one or more pathways for regulating the flow of air. For example, in the exemplary implementation of FIG. 1, the property 105 includes a supply air pathway 112 and a return air pathway 118 for supplying air from the airflow system 110 and returning air to the airflow system 110, respectively. Depending on the implementation, the airflow system 110 may include multiple sets of supply air pathways and/or return air pathways. The supply air pathway 112 and/or return air pathway 118 may include a ventilation cover to minimize risk of objects, creatures, debris, or other items entering or exiting the supply air pathway 112 and/or return air pathway 118.

In the exemplary implementation of FIG. 1, the system 100 includes a first sensor 114 placed proximate to the supply air pathway 112 and a second sensor 116 placed proximate to the return air pathway 118. Depending on the implementation, the first sensor 114 and/or the second sensor 116 may be placed near the airflow system 110, on the ventilation covers (e.g., as depicted in FIG. 1), next to the ventilation covers, etc. Depending on the implementation, the first sensor 114 and the second sensor 116 may be individual sensors, sensors as part of smart devices, sensor arrays transmitting a signal to a separate external device, etc.

In some implementations, the first sensor 114 may be a sensor (e.g., a comfort sensor, supply airflow sensor, etc.) that measures a supply temperature (e.g., temperature of air passing through or exiting the pathway) of the supply air pathway 112. In further implementations, the first sensor 114 additionally measures other parameters of the air in the supply air pathway 112, such as an air pressure (e.g., an atmospheric static pressure) or a relative humidity of air in the supply air pathway 112. Similarly, depending on the implementation, the second sensor 116 may be a sensor (e.g., a filter sensor, return airflow sensor, etc.) that measures a return temperature and/or return atmospheric static pressure of the return air pathway 118. In some implementations, the system 100 includes additional sensors, such as a third sensor 111 (e.g., a water sensor, a leak sensor, etc.). In some such implementations, the third sensor 111 may measure parameters of the airflow system 110 and/or an area immediately proximate the airflow system 110. Depending on the implementation, some such implementations may include a temperature of the airflow system 110, a temperature of an area surrounding the airflow system 110, presence of water near the airflow system 110, humidity in the air surrounding the airflow system 110, etc. Additionally, the system 100 may include space sensors (not shown) for particular spaces (e.g., rooms, apartments, offices, etc.). In some such implementations, the space sensor(s) measure parameters of the air in the particular space, such as temperature, humidity, relative humidity compared to other spaces, etc.

Depending on the implementation, the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors may transmit the data directly to a cloud server 130, to a wireless hub 115, and/or directly to an analysis server 150. In some implementations, the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors transmit measurements in real or near-real time (e.g., constant updates). In further implementations, the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors transmit measurements in batches (e.g., once per hour, once per day, once per week, etc.). In still further implementations, the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors transmit the measurements responsive to an indication from a user (e.g., via the cloud server 130, hub 115, analysis server 150, etc.).

In some implementations, the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors are designed to be activated and used by a non-professional or otherwise a person without any certifications or experience in HVAC-related installations (i.e., the sensors may be DIY). In further such implementations, the sensors are battery-operated and wirelessly transmit any gathered data, for example to the hub 115. Depending on the implementation, the sensors may have a user interface (UI) for a user to perform various functionalities (e.g., naming the sensor, indicating where to transmit data, connecting to a wireless network, indicating where the sensor is located and/or should be located, etc.). In other implementations, the sensors are designed to be turned on and left in a predetermined location.

In further implementations, the analysis server 150 may receive additional information regarding system performance and associated parameters. For example, the analysis server 150 may receive, retrieve, or otherwise access data from other databases (e.g., a weather database, government database, etc.), third party sensors (e.g., weather monitors, outside air quality sensors, etc.), and/or other such resources. Additionally or alternatively, a user may utilize a user interface to input additional data, remove data, select a period of time for measurements, etc.

Depending on the implementation, the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors may be part of or be a smart device. For example, the sensor may be part of a single smart device, such as a smart television, smart refrigerator, smart doorbell, or any other similar smart device. In further implementations, the sensor may be part of a network of devices, such as a security system, a lighting system, or any other similar series of devices communicating with one another. The first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors may further be a built-in capability of another sensor (e.g., a combined comfort/filter sensor including capabilities of the first sensor 114 and second sensor 116) or additional sensor of a sensor network, for example, a camera or series of cameras, a motion detector, a temperature sensor, an airflow sensor, a smoke detector, a carbon monoxide detector, or any similar sensor.

The hub 115 may enable the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors to communicate with the cloud server 130, the analysis server 150, and/or any other such external computing server or device. The hub 115 may support wired or wireless communications, such as USB, Bluetooth, Wi-Fi Direct, Near Field Communication (NFC), etc. The hub 115 may enable the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors to communicate with various devices, servers, etc., via a wireless communication network such as a fifth-, fourth-, or third-generation cellular network (5G, 4G, or 3G, respectively), a Wi-Fi network (e.g., 802.11 standards), a WiMAX network, a wide area network (WAN), a local area network (LAN), etc. The hub 115 may further operate to format messages transmitted between the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors and the cloud network 130, analysis server 150, and/or other such devices or servers; process data from the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors; transmit communications to the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensors; etc.

In some implementations, the hub 115 functions as an edge computer to perform one or more processing and/or pre-processing steps rather than analysis server 150. For example, depending on the implementation, the hub 115 may preprocess the sensor data by determining a rate of change, a relative value compared to other metrics (e.g., an outside temperature, an outside air quality, etc.), etc., as discussed in more detail below with regard to FIG. 2.

In some implementations, the analysis server 150 includes a stored cycle logic model 160, which retrieves data from a stored cycle data database 162. The cycle logic model may analyze data from the stored cycle data database 162 (e.g., data from the first sensor 114 and/or second sensor 116) and generate a cycle type classification 165, as described in more detail with regard to at least FIGS. 4 and 6 below. In further implementations, the cycle logic model 160 is or includes a machine learning model trained on data in the stored cycle data database 162.

Depending on the implementation, the hub 115, cloud server 130, and/or analysis server 150 may include a processor, a communications interface, a memory, and/or other similar components (e.g., a display) for processing, analyzing, and/or providing data. For example, the hub 115, cloud server 130, and/or analysis server 150 may include any suitable number of processors and/or processor types. In some implementations, the processor(s) may include one or more CPUs and one or more graphics processing units (GPUs), for example. Generally, the processors may be configured to execute software instructions stored in a memory, which may include one or more persistent memories (e.g., a hard drive and/or solid-state memory) may store one or more applications, models, algorithms, etc.

The hub 115, cloud server 130, and/or analysis server 150 may be communicatively coupled to the first sensor 114, the second sensor 116, and/or another computing device associated with the property 105. For example, the hub 115, cloud server 130, and/or analysis server 150 may communicate with the sensors (e.g., 114 and 116) and/or computing devices via USB, Bluetooth, Wi-Fi Direct, Near Field Communication (NFC), etc.

It will be understood that the above disclosure is one example and does not necessarily describe every possible implementation. As such, it will be further understood that alternate implementations may include fewer, alternate, and/or additional steps or elements.

Referring next to FIG. 2, a hub system 200 collects data from one or more sensors and transmits the data to a cloud server 230. Depending on the implementation, the hub system 200 may be similar to, be, include, or otherwise be associated with components of system 100 as described above with regard to FIG. 1. In some implementations, the hub system 200 includes one or more sensors 210 (e.g., a first sensor 114, a second sensor 116, a third sensor 111, a space sensor, etc.). In further implementations, the hub system 200 includes multiple copies of at least some of the sensors 210 (e.g., two first sensors 114, two second sensors 116, two third sensors 111, two space sensors, etc.). In still further implementations, at least some of the additional copies of the sensors 210 are part of or are disposed proximate to appliances or locations at risk of leaking on a property (e.g., washing machines, water heaters, etc.). As described above with regard to FIG. 1, the sensors 210 may be DIY sensors designed for an average layperson to implement without requiring physical wiring to a thermostat or other such airflow system control apparatuses. The hub system 200 further includes a hub 215 (e.g., similar to hub 115) and a router 220. The hub 215 receives data from the sensors 210 via a local wireless sensor network 212, which may be a wireless network (e.g., using Wi-Fi connections, Bluetooth connections, etc.) and communicates with the router 220 via a local network connection 217. Depending on the implementation, the local network connection 217 may be a Wi-Fi connection, Bluetooth connection Ethernet connection, LAN connection, WAN connection, etc. The router 220 then provides collected data to the cloud server 230 via an internet connection 222.

In some implementations, the hub 215 performs one or more edge computing operations prior to transmitting the data retrieved from the sensors 210 to the cloud 230. For example, depending on the implementation, the hub 215 may preprocess the sensor data by determining a rate of change, a relative value compared to other metrics (e.g., an outside temperature, an outside air quality, etc.), etc. In further implementations, the hub 215 determines a cycle type for an airflow system (e.g., airflow system 110) as described herein and transmits the data to the cloud server 230 for further analysis, storage, etc. In still further implementations, the hub 215 pulls data from the cloud server 230 for edge computing operations and transmits the analyzed, generated, and/or otherwise processed data back to the cloud server 230.

It will be understood that the above disclosure is one example and does not necessarily describe every possible implementation. As such, it will be further understood that alternate implementations may include fewer, alternate, and/or additional steps or elements.

FIG. 3 is a block diagram of an exemplary architecture for a computing system 300 to implement the techniques described herein. In the exemplary embodiment of FIG. 3, the computing system 300 includes one or more sensors 310 that relay gathered data to a hub 315, which communicates with a cycle analysis module 330, data storage module 350, and system health analysis module 335. An output API 360 then enables various modules, platforms, nodes, etc. (e.g., an application platform 370, dashboard platform 380, operations node 390, etc.) to access and utilize the generated data.

In some implementations, the sensors 310 may include a first sensor (e.g., first sensor 114) for measuring data regarding air supplied by an airflow system (e.g., airflow system 110), a second sensor (e.g., second sensor 116) for measuring data regarding air received by an airflow system, a third sensor (e.g., third sensor 111) for measuring data regarding water presence in an area surrounding an airflow system, a space sensor for measuring data regarding airflow in one or more spaces in which airflow is controlled, moderated, or otherwise affected by the airflow system, and/or any other such sensor as described herein.

In further implementations, the hub 315 utilizes a hub API 320 to pull data from a hub data database 325. In some such implementations, the hub 315 utilizes the hub API 320 by calling the hub API 320 using firmware for the hub 315. In further such implementations, the hub API 320 is accessed via a wireless connection with another device, and the hub 315 uses an HTTP call function to call the hub API 320 when accessing the hub data database 325. Depending on the implementation, then, the hub data database 325 may be a memory of the hub 315, a server that the hub 315 is communicatively coupled to, etc. Further depending on the implementation, the hub data database 325 may include raw data from the sensors 310 that the hub 315 stores at the hub data database 325, preprocessed data (e.g., as described below with regard to FIG. 6), etc.

In some implementations, a cycle analysis module 330 accesses the hub data database 325. The cycle analysis module 330 then analyzes the data retrieved from the hub data database 325. Depending on the implementation, the cycle analysis module 330 may be part of an analysis server (e.g., analysis server 150), part of a hub (e.g., hub 315), part of an additional electronic device (e.g., a third party analysis device), etc. After processing and/or analyzing the data retrieved from the hub data database 325, the cycle analysis module 330 provides the analyzed data (e.g., airflow cycle data) to a data storage module 350.

In some implementations, the cycle analysis module 330 analyzes the data retrieved from the one or more sensors 310 and determines airflow system cycle data, such as (i) a rate of change of the supply temperature, (ii) a supply temperature of the air supplied via the supply air pathway relative to outside air conditions, (iii) a return temperature of the air received via the return air pathway relative to outside air conditions, (iv) an airflow pressure fluctuation, (v) a temperature difference between the supply temperature and an return temperature of the air received via the return air pathway, (vi) a trend of the temperature difference over time, (vii) a relative value of the supply temperature against a predefined threshold, and/or (viii) some other such data as described herein.

In some implementations, the cycle analysis module 330 and/or other such modules, components, systems, methods, etc. described herein may use machine learning techniques to classify operations of a system based on the effects of observed or latent variables. Similarly, some implementations described herein may include automated machine learning to generate representations of cycle data based on received sensor data, process sensor data, and/or perform other functionality as described elsewhere herein.

Although the methods described elsewhere herein may not directly mention machine learning techniques, such methods may be read to include such machine learning for any determination or processing of data that may be accomplished using such techniques. In some implementations, such machine-learning techniques may be implemented automatically upon occurrence of certain events or upon certain conditions being met. Use of machine learning techniques, as described herein, may begin with training a machine learning program, or such techniques may begin with a previously trained machine learning program.

A processor or a processing element may be trained using supervised, semi-supervised, or unsupervised machine learning, and the machine learning program may employ a neural network, which may be a convolutional neural network, a deep learning neural network, or a combined learning module or program that learns in two or more fields or areas of interest. Machine learning may involve identifying and recognizing patterns in existing data in order to facilitate making predictions for subsequent data. Models may be created based upon example inputs of data in order to make valid and reliable predictions for novel inputs.

Additionally or alternatively, the machine learning programs may be trained by inputting sample data sets or certain data into the programs. The machine learning programs may utilize deep learning algorithms that are primarily focused on pattern recognition and may be trained after processing multiple examples. The machine learning programs may include Bayesian program learning (BPL), image or object recognition, optical character recognition, and/or natural language processing, either individually or in combination. The machine learning programs may also include natural language processing, semantic analysis, automatic reasoning, and/or machine learning.

In supervised machine learning, a processing element may be provided with example inputs and their associated outputs, and may seek to discover a general rule that maps inputs to outputs, so that when subsequent novel inputs are provided the processing element may, based upon the discovered rule, accurately predict the correct or a preferred output. In unsupervised machine learning, the processing element may be required to find its own structure in unlabeled example inputs.

After training, machine learning programs (or information generated by such machine learning programs) may be used to evaluate additional data. Such data may be related to captured sensor data for a particular property, as described herein. The trained machine learning programs (or programs utilizing models, parameters, or other data produced through the training process) may then be used for determining, assessing, analyzing, predicting, estimating, evaluating, or otherwise processing new data not included in the training data. Such trained machine learning programs may, therefore, be used to perform part or all of the analytical functions of the methods described elsewhere herein.

In some implementations, the computing system 300 trains a machine learning model according to the above by inputting training data consisting of sensor data and corresponding cycle types for an airflow system. For example, the computing system 300 may train the machine learning model by using airflow temperature, humidity, pressure, etc. along with a corresponding cycle type determination to train the model of factors indicative of a heating cycle, cooling cycle, fan cycle, etc. Depending on the implementation, the sensor data and/or other such data associated with the airflow system may be labeled as input data, while the cycle type determination may be labeled as output data for training by the computing system 300.

In further implementations, the machine learning model may be trained or re-trained according to determinations by the model. For example, when being used by a user (e.g., after an initial training session), the machine learning model may make a determination as to the cycle type of an airflow system. The user or an alternative source (e.g., a database, thermostat, etc.) may indicate to the machine learning model that a determination was accurate (e.g., reinforcing the training) or incorrect (e.g., correcting or updating the model). As such, the computing system 300 may further use the machine learning model for further updating and/or re-training. Further, the machine learning model that was updated and/or re-trained may be used for subsequent analyses of input data to determine cycle types.

In some implementations, the data storage module 350 receives generated data from the cycle analysis module 330. The data storage module 350 may include a cycle database 352, a data stream module 354, a user data database 356, a data storage platform 358, etc. In some implementations, the cycle database 352 stores the airflow cycle data generated by the cycle analysis module 330. The data stream module 354 may, using the airflow cycle data stored at the cycle database 352, generate a cycle type table representative of one or more determined airflow cycle types (e.g., as determined at the cycle analysis module 330). In further implementations, another module (e.g., the cycle database 352, cycle analysis module 330, etc.) generates the cycle type table and the data stream module 354 instead pulls the cycle type table and facilitates streaming of the cycle type table and/or data associated with the cycle type table to the data storage platform 358.

In some implementations, the cycle database 352 and/or the data storage platform 358 additionally pulls and/or receives data from a system health analysis module 335. Depending on the implementation, the system health analysis module 335 may determine a health status of the airflow system, access previous health statuses of the airflow system, store data associated with the health of the airflow system, etc. In further implementations, the cycle database 352, data stream module 354, data storage platform 358, etc. may use data from the system health analysis module 335 to generate, update, and/or otherwise modify the cycle type table.

In further implementations, the cycle database 352, data stream module 354, and/or the data storage platform 358 interfaces with the user data database 356 to generate the cycle type table using user data. For example, the user data database 356 may include a name, address, account number, stored preference(s), registered airflow system(s), registered properties, etc. Depending on the implementation, the data storage module 350 generates the cycle type table in accordance with the user data database 356.

The data storage platform 358 stores the cycle type table and/or any generated, calculated, measured, or otherwise retrieved data associated with such. In some implementations, the data storage platform 358 generates additional information associated with airflow cycles and/or airflow cycle types, such as the cycle type table, a temperature tracking graph (e.g., graph 500A as described below with regard to FIG. 5A), a runtime performance graph (e.g., graphs 400A, 400B as described with regard to FIGS. 4A-4D below), etc.

The output API 360 then enables various platforms, such as an application platform 370, a dashboard platform 380, an operations node 390, etc., to access cycle data from the data storage module 350. In some implementations, the output API 360 interfaces with the data storage platform 358 to provide a generated airflow cycle type table and/or other such generated representations of airflow system data, airflow cycle data, user data, etc. Depending on the implementation, the application platform 370 may be an application stored on and/or operated by a mobile device associated with a user. In further implementations, the dashboard platform 380 may be a dashboard associated with an electronic device displaying a plurality of cycle tables and/or other such graphical representations (as described above) for one or more users associated with the dashboard platform 380 (e.g., as users of a third party partner dashboard program). Similarly, the operations node 390 may provide a node for access to the output API 360 for various other programs, platforms, applications, websites, etc. with permission to request access to the information in question.

It will be understood that the above disclosure is one example and does not necessarily describe every possible implementation. As such, it will be further understood that alternate implementations may include fewer, alternate, and/or additional steps or elements.

FIGS. 4A, 4B, 4C, and 4D depicts a series of user interfaces (UIs) 400A, 400B, 400C, and 400D, respectively (collectively referred to as “UIs 400”). Each of the UIs 400 depicts different views of an exemplary mobile application (e.g., application platform 370) depicting exemplary sets of information for a user regarding airflow cycles for an airflow system (e.g., airflow system 110). UI 400A depicts a series of cooling system cycles and an average airflow cooling that occurred throughout a week. For example, in the exemplary depiction of 400A, the airflow system cooled the designated area by an average of 11 degrees each day from Sunday to Wednesday and cooled the designated area by an average of 12 degrees on Thursday. Further, the UI 400B depicts the runtime of the airflow system for each of those days, with longer runtimes on Tuesday and Thursday in particular, as well as a high and low temperature for each day.

The UI 400C depicts a set of variable values for different cycle operations throughout a day. Depending on the implementation, such variables may be include the time of operation, supply air temperature, return air temperature, overall performance temperature, difference between supply and return temperatures, outside air temperature, temperature of the airflow system (e.g., leak sensor temperature), air pressure changes, supply air pressure, return air pressure, overall runtime, determined operation mode for the cycle (e.g., as determined at cycle analysis module 330), humidity of supply air, humidity of return air, etc. Further, the UI 400D may depict similar information such as the length of each operation cycle and relative temporal placement. Depending on the implementation, the UI 400D may further depict information such as an overall runtime, a number of operation cycles, a daily high/low value, a longest/shortest cycle value, details of the cycle, etc. In some implementations, interacting with an element of one of the UIs 400 may lead to another UI 400.

It will be understood that the above disclosure is one example and does not necessarily describe every possible implementation. As such, it will be further understood that alternate implementations may include fewer, alternate, and/or additional steps or elements.

FIG. 5A depicts an exemplary graph 500A depicting a trend in supply air temperature, return air temperature, and leak air temperature (e.g., temperature near an airflow system such as airflow system 110) over time. Depending on the implementation, a dashboard (e.g., dashboard platform 380) or mobile application (e.g., application platform 370) may depict the graph 500A to a user. In some implementations, the graph 500A includes additional or alternative metrics (e.g., from additional sensors, etc.). In some implementations, the graph 500A is representative of a particular day, week, month, and/or other such time period in which an airflow system performs various operation cycles. Depending on the implementation, the time period is defined by a user, automatically determined based on activity, automatically determined based on lack of activity (e.g., representative of potential malfunction), etc. In the exemplary embodiment of FIG. 5A, spikes in temperature may be representative of heating cycles. For example, 8:30 to 8:45, 9:30 to 9:45, 10:30 to 10:45, etc. may each be periods in which the system of FIG. 5A operates according to heating cycles.

FIG. 5B depicts an exemplary cycle table 500B depicting one or more operation cycles for an airflow system (e.g., airflow system 110) over time. Depending on the implementation, the cycle table 500B may include metrics such as air conditioning (AC) mode 502 (e.g., an operation mode, cycle mode, etc.), a thermostat zone 504 (e.g., depicting where the airflow system affects), an outside air (OA) temperature and/or relative humidity (RH) 506, a pressure change in water 508, a performance metric 510, a supply air/return air temperature 512, a leak temperature 514, a time of operation 516, a runtime 518, a date of operation 520, etc. Depending on the implementation, the cycle table 500B may include additional data, alternative data, less data, etc.

In further implementations, the cycle table 500B may have options to sort the information based on one or more of the included metrics (e.g., AC mode, time of day, runtime, date, etc.). In still further implementations, the cycle table 500B may include user data, such as a user name, address, email address, etc. Depending on the implementation, an application and/or dashboard (e.g., an application platform 370, dashboard platform 380, etc.) may include multiple cycle tables similar to cycle table 500B corresponding to multiple users or locations, and a viewer may switch between users, locations, etc.

It will be understood that the above disclosure is one example and does not necessarily describe every possible implementation. As such, it will be further understood that alternate implementations may include fewer, alternate, and/or additional steps or elements.

FIG. 6 is a flow diagram of an exemplary computer-implemented method 600 for identifying and classifying airflow cycle types. The method 600 may be implemented by one or more processors of a computing system such as analysis server 150. Alternatively or additionally, the method 600 may be implemented by one or more processors of other computing devices, servers, components, etc. of a distributed system such as system 100 as described with regard to FIG. 1 above.

At block 602, the analysis server 150 may receive airflow system data representative of at least supply airflow data and return airflow data. In some implementations, the supply airflow data originates from a first sensor (e.g., first sensor 114) disposed proximate to a supply air pathway (e.g., supply air pathway 112) of an airflow system (e.g., airflow system 110). In some such implementations, the supply airflow data from the first sensor 114 may include a supply temperature of air supplied via, traveling through, and/or exiting from the supply air pathway 112. In further implementations, the supply airflow data may include a humidity level of the air supplied via, traveling through, and/or exiting from the supply air pathway 112.

Depending on the implementation, the supply temperature may be collected by the first sensor 114 during an airflow cycle facilitated by the airflow system 110. In further implementations, the supply airflow data from the first sensor 114 may additionally or alternatively include a supply air pressure (e.g., atmospheric static pressure) of air traveling through and/or exiting from the supply air pathway 112, collected during the airflow cycle. Depending on the implementation, the first sensor 114 may be disposed proximate to the supply air pathway, such as in the supply air pathway 112, on a ventilation cover (e.g., a primary supply vent register), near a ventilation cover, and/or any other similar such location.

Similarly, the return airflow data may originate from a second sensor (e.g., second sensor 116) disposed proximate to a return air pathway (e.g., return air pathway 118) of the airflow system 110. In some implementations, the second sensor 116 may measure the return temperature and/or static pressure of air traveling through and/or exiting the return air pathway 118 and collected by the second sensor 116 during an airflow cycle facilitated by the airflow system 110, similar to the first sensor 114 above. Depending on the implementation, the second sensor 116 may be disposed proximate to the return air pathway, such as in the return air pathway 118, on a ventilation cover (e.g., a primary supply vent register), near a ventilation cover, and/or any other similar such location. In further implementations, the airflow cycle during which the second sensor 116 collects return airflow data may be the same airflow cycle as the airflow cycle during which the first sensor 114 collects supply airflow data. In other implementations, the airflow cycles are different airflow cycles.

At block 604, the analysis server 150 may receive airflow system data representative of moisture data and/or space data (e.g., of a space affected by the airflow system 110). In some such implementations, the analysis server 150 may receive such additional information regarding airflow from one or more additional sensors, collected during an airflow cycle facilitated by the airflow system 110. For example, the system 100 may include an a third sensor, such as third sensor 111, disposed proximate the airflow system 110, a space sensor disposed in a space affected by the airflow system 110), and/or other such sensors. Depending on the implementation, the additional sensor(s) may measure an ambient temperature, ambient humidity, ambient air pressure, ambient condensation, water vapor presence, moisture presence, condensation presence, water presence, airflow system 110 temperature, etc. The additional sensor(s) may then transmit the measured data to the analysis server 150 as described above with regard to FIG. 1. Additionally or alternatively, a user may utilize a user interface to input additional data, remove data, select a period of time for measurements, etc.

In some implementations, the sensors (e.g., the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensor) are wireless self-install sensors (e.g., do-it-yourself (DIY) sensors). In some such implementations, the sensors are battery operated and are able to placed and set-up by a layperson without requiring an outside contractor or other such third party to install the sensors. As such, the analysis server 150 may retrieve and analyze data from sensors without extensive cost, footprint, setup time, or technical knowledge required for connecting sensors to a thermostat, as may be required by traditional techniques.

Depending on the implementation, the sensors (e.g., the first sensor 114, the second sensor 116, the third sensor 111, space sensors, and/or any other such sensor) transmit collected airflow system data to the analysis server 150 and/or the hub (e.g., hub 115) at a specified interval, in real time, responsive to a command from a user, some combination thereof, and/or via any other such technique as described herein. In some such implementations, a user may set the specified interval via the sensor in question, the hub 115, the analysis server 150, and/or another electronic device communicatively coupled to the system 100. In further such implementations, the sensor(s) may include a default interval that a user may change. Depending on the implementation, the sensors may transmit the data to the hub via a radio frequency, Wi-Fi connection, Bluetooth connection, WPS connection, Ethernet connection, and/or any other such connection.

At block 606, the analysis server 150 may analyze the airflow system data (e.g., the supply airflow data, return airflow data, moisture data, space data, and/or other such data) to generate system cycle data associated with an airflow cycle (e.g., the airflow cycle(s) during which the sensors collected the respective airflow system data). In some implementations, the analysis is based on at least the supply temperature of the air supplied via the supply air pathway and the static pressure of the air received via the return air pathway. In further implementations, the analysis is further based on: (i) a rate of change of the supply temperature, (ii) a supply temperature of the air supplied via the supply air pathway relative to outside air conditions, (iii) a return temperature of the air received via the return air pathway relative to outside air conditions, (iv) an airflow pressure fluctuation, (v) a temperature difference between the supply temperature and an return temperature of the air received via the return air pathway, (vi) a trend of the temperature difference over time, or (vii) a relative value of the supply temperature against a predefined threshold, and/or (vii) any other similar metric.

In some implementations, the analysis server 150 may analyze the airflow system data according to a trained machine learning model, as described in more detail above. For example, the analysis server 150 may receive the airflow system data as an input and may generate an output cycle type determination by utilizing the trained machine learning model. As such, machine learning techniques described herein may apply to the analysis of the airflow system data by the analysis server 150.

In still further implementations, the analysis server 150 may receive and analyze data in a preprocessing step to generate an initial metric such as those listed above. For example, the analysis server 150 may receive multiple supply temperatures associated with the supply air pathway 112. Using the multiple supply temperatures, the analysis server 150 may calculate a rate of change of the supply temperatures. Similarly, the analysis server 150 may receive information such as relevant threshold(s) and/or additional data (e.g., outside weather/condition data) and may process received airflow system data in accordance with the additional information. In further implementations, another electronic device may perform part or all of the analysis as described herein. For example, a hub device (e.g., hub 115) may be a computing device that performs some or all of the analysis (e.g., via edge computing), as described above with regard to FIG. 2. In further implementations, the additional electronic device performs preprocessing step(s) such as those outlined above and provides the processed data to the analysis server 150 as airflow system data.

At block 608, the analysis server 150 may classify, based on the airflow system cycle data generated at block 606, an airflow cycle type for the airflow cycle facilitated by the airflow system 110. Depending on the implementation, the airflow cycle type may be a heating cycle, a cooling cycle, a fan cycle, and/or any other appropriate such airflow cycle type as described herein.

At block 610, the analysis server 150 may generate a cycle type table representative of the airflow cycle type. Depending on the implementation, the analysis server 150 may perform blocks 602 through 608 and/or operations similar to blocks 602 through 608 multiple times to classify multiple airflow cycles prior to generating the cycle type table. In some such implementations, the cycle type table is representative of each of the multiple airflow cycles. In further implementations, the analysis server 150 performs blocks 602 through 608 and/or operations similar to blocks 602 through 608 one or more times after generating the cycle table. In some such implementations, the analysis server 150 updates the cycle table after classifying each airflow cycle.

At block 612, the analysis server 150 causes a user device to display the cycle type table to a user. In some implementations, the user device includes an application platform (e.g., application platform 370) for a mobile application to display the table (e.g., as depicted in application UI 400C). In further implementations, the user device additionally or alternatively includes a dashboard platform (e.g., dashboard platform 380) for an electronic device to display the table. Depending on the implementation, the user device may include additional or alternate methods for displaying the cycle type table. In further implementations, the analysis server 150 may additionally or alternatively cause the analysis server 150 to display additional information, such as a graphical representation of changes in temperature throughout hours, days, weeks, months, etc. of recorded airflow cycles (e.g., as described above with regard to FIGS. 4A-5B).

It will be understood that the above disclosure is one example and does not necessarily describe every possible implementation. As such, it will be further understood that alternate implementations may include fewer, alternate, and/or additional steps or elements.

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.

The systems and methods described herein are directed to an improvement to computer functionality, and improve the functioning of conventional computers. Additionally, certain implementations are described herein as including logic or a number of routines, subroutines, applications, or instructions. These may constitute either software (e.g., code embodied on a non-transitory, machine-readable medium) or hardware. In hardware, the routines, etc., are tangible units capable of performing certain operations and may be configured or arranged in a certain manner. In example implementations, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.

In various implementations, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Accordingly, the terms “module”, “hardware module”, and/or similar such terms should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. Considering implementations in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.

Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) that connect the hardware modules. In implementations in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).

The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example implementations, comprise processor-implemented modules.

Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented hardware modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example implementations, the processor or processors may be located in a single location (e.g., within a home environment, an office environment or as a server farm), while in other implementations the processors may be distributed across a number of locations.

The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example implementations, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example implementations, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.

It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘______’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based upon any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this disclosure is referred to in this disclosure in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning.

Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

As used herein any reference to “one implementation” or “an implementation” means that a particular element, feature, structure, or characteristic described in connection with the implementation is included in at least one implementation. The appearances of the phrase “in one implementation” in various places in the specification are not necessarily all referring to the same implementation.

Some implementations may be described using the expression “coupled” and “connected” along with their derivatives. For example, some implementations may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still cooperate or interact with each other. The implementations are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

In addition, use of the “a” or “an” are employed to describe elements and components of the implementations herein. This is done merely for convenience and to give a general sense of the description. This description, and the claims that follow, should be read to include one or at least one and the singular also may include the plural unless it is obvious that it is meant otherwise.

The patent claims at the end of this patent application are not intended to be construed under 35 U.S.C. § 112 (f) unless traditional means-plus-function language is expressly recited, such as “means for” or “step for” language being explicitly recited in the claim(s). The systems and methods described herein are directed to an improvement to computer functionality, and improve the functioning of conventional computers.

This detailed description is to be construed as exemplary and does not describe every possible implementation, as describing every possible implementation would be impractical, if not impossible. One could implement numerous alternate implementations, using either current technology or technology developed after the filing date of this application.

Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for evaluating properties, through the principles disclosed herein. Therefore, while particular implementations and applications have been illustrated and described, it is to be understood that the disclosed implementations are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

1. A system for identifying and classifying airflow cycle types, the system comprising:

an airflow system configured to receive air via a return air pathway and supply air via a supply air pathway;

a first sensor disposed proximate to the supply air pathway of the airflow system and configured to, in an airflow cycle facilitated by the airflow system, collect supply airflow data associated with the supply air pathway, wherein the supply airflow data includes at least a supply temperature of the air supplied via the supply air pathway;

a second sensor disposed proximate to the return air pathway of the airflow system and configured to, in the airflow cycle facilitated by the airflow system, collect return airflow data associated with the return air pathway, wherein the return airflow data includes at least a return temperature of the air received via the return air pathway; and

an electronic device including one or more processors communicatively coupled to a memory storing one or more instructions that, when executed, cause the one or more processors to: receive airflow system data representative of at least the supply airflow data and the return airflow data; analyze the airflow system data to generate airflow system cycle data associated with the airflow cycle and based at least on the supply temperature of the air supplied via the supply air pathway and the return temperature of the air received via the return air pathway; and classify, based on the airflow system cycle data, an airflow cycle type of the airflow cycle facilitated by the airflow system.

2. The system of claim 1, wherein the return airflow data further includes at least a static pressure of the air received via the return air pathway and the airflow system cycle data is further generated based on the static pressure of the air received via the return air pathway.

3. The system of claim 1, wherein the supply airflow data further includes at least a relative humidity level of the air supplied via the supply air pathway and the airflow system cycle data is further generated based on the relative humidity level of the air supplied via the supply air pathway.

4. The system of claim 1, wherein:

the system further comprises a third sensor disposed proximate to the airflow system and configured to collect moisture data associated with the airflow system, including at least a temperature of an area proximate to the airflow system; and

the airflow system cycle data is further generated based on the at least the temperature of the area proximate to the airflow system.

5. The system of claim 1, wherein:

the system further comprises a space sensor configured to collect space data associated with an area in which the space sensor is disposed, including at least one of (i) an air temperature associated with the area or (ii) a relative humidity of the area; and

the airflow system cycle data is further generated based on the at least one of (i) the air temperature associated with the area or (ii) the relative humidity of the area.

6. The system of claim 1, wherein the airflow system cycle data includes at least one of: (i) a rate of change of the supply temperature, (ii) a supply temperature of the air supplied via the supply air pathway relative to outside air conditions, (iii) a return temperature of the air received via the return air pathway relative to outside air conditions, (iv) an airflow pressure fluctuation, (v) a temperature difference between the supply temperature and an return temperature of the air received via the return air pathway, (vi) a trend of the temperature difference over time, or (vii) a relative value of the supply temperature against a predefined threshold.

7. The system of claim 1, wherein the airflow cycle type is a first airflow cycle type of a plurality of airflow cycle types for a plurality of airflow cycles facilitated by the airflow system and the memory further stores instructions that, when executed, cause the one or more processors to:

generate a cycle type table representative of the plurality of airflow cycle types; and

cause a user device to display the cycle type table to a user.

8. The system of claim 1, further comprising a hub data aggregation device configured to aggregate at least the supply airflow data and the return airflow data and transmit the airflow system data to the server.

9. The system of claim 8, wherein the hub data is configured to perform a preprocessing operation on the supply airflow data and the return airflow data to generate the airflow system data.

10. The system of claim 1, wherein the first sensor is a first wireless self-install sensor and the second sensor is a second wireless self-install sensor.

11. A method for identifying and classifying an airflow cycle type, the method comprising:

receiving, by one or more processors, airflow system data representative of at least supply airflow data collected by a first sensor disposed proximate to a supply air pathway of an airflow system and return airflow data collected by a second sensor disposed proximate to a return air pathway of the airflow system, wherein: the supply airflow data includes at least a supply temperature of the air supplied via the supply air pathway collected during an airflow cycle facilitated by the airflow system, and the return airflow data includes at least a return temperature of the air received via the return air pathway collected during an airflow cycle facilitated by the airflow system;

analyzing, by the one or more processors and based at least on the supply temperature of the air supplied via the supply air pathway and the return temperature of the air received via the return air pathway, the airflow system data to generate system cycle data associated with the airflow cycle; and

classifying, by the one or more processors and based on the airflow system cycle data, an airflow cycle type of the airflow cycle facilitated by the airflow system.

12. The method of claim 11, wherein the return airflow data further includes at least a static pressure of the air received via the return air pathway and the airflow system cycle data is further generated based on the static pressure of the air received via the return air pathway.

13. The method of claim 11, wherein the supply airflow data further includes at least a relative humidity level of the air supplied via the supply air pathway and the airflow system cycle data is further generated based on the humidity level of the air supplied via the supply air pathway.

14. The method of claim 11, wherein:

the system further comprises a third sensor disposed proximate to the airflow system and configured to collect moisture data associated with the airflow system, including at least a temperature associated with the airflow system; and

the airflow system cycle data is further generated based on the at least the temperature associated with the airflow system.

15. The method of claim 11, wherein:

the system further comprises a space sensor configured to collect space data associated with an area in which the space sensor is disposed, including at least one of (i) an air temperature associated with the area or (ii) a relative humidity of the area; and

the airflow system cycle data is further generated based on the at least one of (i) the air temperature associated with the area or (ii) the relative humidity of the area.

16. The method of claim 11, wherein the airflow system cycle data includes at least one of: (i) a rate of change of the supply temperature, (ii) a supply temperature of the air supplied via the supply air pathway relative to outside air conditions, (iii) a return temperature of the air received via the return air pathway relative to outside air conditions, (iv) an airflow pressure fluctuation, (v) a temperature difference between the supply temperature and an return temperature of the air received via the return air pathway, (vi) a trend of the temperature difference over time, or (vii) a relative value of the supply temperature against a predefined threshold.

17. The method of claim 11 wherein the airflow cycle type is a first airflow cycle type of a plurality of airflow cycle types for a plurality of airflow cycles facilitated by the airflow system and the method further comprises:

generating, by the one or more processors, a cycle type table representative of the plurality of airflow cycle types; and

causing, by the one or more processors, a user device to display the cycle type table to a user.

18. The method of claim 11, further comprising a hub data aggregation device configured to aggregate at least the supply airflow data and the return airflow data and transmit the airflow system data to the server.

19. The method of claim 18, wherein the hub data is configured to perform a preprocessing operation on the supply airflow data and the return airflow data to generate the airflow system data.

20. The method of claim 11, wherein the first sensor is a first wireless self-install sensor and the second sensor is a second wireless self-install sensor.