WO2025019030A1 - Prediction of office building occupancy from building resource consumption data for optimized energy management - Google Patents

Abstract

A controller controls building energy loads according to building occupancy using a meter score engine (121), a prediction engine (131) and an operation scheduler (141). Meter score engine (121) determines (521) a meter score for each of a plurality of consumption meters. The score is determined by an algorithm that combines correlations between the meter consumption data (101) and time series variables (102) related to expected occupancy time periods and daily temperature. Prediction engine (131) determines (531) an estimation of building occupancy for a target time period using consumption data (101) from one or more best meters. Operation scheduler generates (541) a schedule of operation mode of building energy loads for the target time period based on the estimation of building occupancy and optimized for energy conservation. Controller controls (551) building energy loads according to the schedule.

Description

PREDICTION OF OFFICE BUILDING OCCUPANCY

FROM BUILDING RESOURCE CONSUMPTION DATA

FOR OPTIMIZED ENERGY MANAGEMENT

TECHNICAL FIELD

[0001] This application relates to building technology. More particularly, this application relates to a controller for optimized energy management of a building and improved building operations efficiency.

BACKGROUND

[0002] Service operators and operations managers of buildings, such as office buildings, are ever seeking to minimize energy expenditures by efficient use of resources, such as heating, cooling, and other services. Predicting occupancy of an office building can help determine quantity of resources, such as electricity and water and natural gas etc., that will be needed to operate and maintain the office building. During low-occupancy periods, entire floors, zones, sections of the building could be closed in order to conserve energy, while others can be scheduled for use on specific days and situations.

[0003] Existing studies have collected building occupancy data using a variety of sensors, including image-based sensors (e.g., infrared, visible light and luminance cameras), motion sensors (passive infrared), radio-based sensors, threshold and mechanical RFID sensors (e.g., ID card swipes at security checkpoints). Once occupancy data is collected, a machine learning algorithm (such as random forest or artificial neural network) is used to learn occupancy patterns and predict future occupancy. Occupancy predictions can then be used proactively and in real time to reduce energy spending in a building. However, occupancy data is not always easily accessible in building control systems or is unavailable for lack of a sensor-based system. Moreover, due to privacy concerns, building managers may be prohibited or reluctant to release occupancy data that includes personal information, such as from ID card swipes.

SUMMARY

[0004] System and method for building resource control based on building occupancy retrieves resource consumption data from various resource consumption meters (e.g., electricity meters, natural gas, fuel oil and water meters installed in the building). From among all resource consumption meters in the building, an algorithm determines correlation scores of the meters related to correlation with building occupancy based on analysis of weighted time series regressors, such as day of week, time of day and recorded temperature, and the best meters are selected by the correlation score. To predict building occupancy for a particular target day, a prediction engine analyzes historical data from the best meters to derive a normalized occupancy value relevant to the target day (e.g., second Tuesday of the month). The real occupancy value prediction is estimated for the target day by conversion of the normalized occupancy value by a standardized factor derived from minimum and maximum building occupancy data for the target time period. An operation scheduler generates a schedule for an energy resource controller based on the occupancy value prediction, which is optimized for energy consumption.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Non-limiting and non-exhaustive embodiments of the present disclosure are described with reference to the following FIGURES, wherein like reference numerals refer to like elements throughout the drawings unless otherwise specified.

[0006] FIG. 1 illustrates a framework example of a controller for building energy loads which optimizes a scheduler for energy management in accordance with embodiments of this disclosure.

[0007] FIG. 2 illustrates an example of mapping occupancy to building operation modes according to embodiments of this disclosure.

[0008] FIG. 3 illustrates an example of time series variables and consumption data for a meter to be correlated in accordance with embodiments of this disclosure.

[0009] FIG. 4 an example of a computing environment within which embodiments of the disclosure may be implemented.

[0010] FIG. 5 illustrates an example of a computer-implemented method for controlling building energy loads according to building occupancy in accordance with embodiments of this disclosure. DETAILED DESCRIPTION

[0011] Methods and systems are disclosed to determine building occupancy for energy management in building operations, such as optimizing a schedule of controlled energy delivery to equipment for comfort of occupants, such as HVAC and lighting during periods of normal occupancy, while minimizing energy consumption during low occupancy periods. With this disclosure, patterns of building occupancy are predicted solely based on reading data of resource consumption meters data rather than reliance on various occupancy-related sensor readings throughout the building. We have found that accurate predictions are possible with this approach, which is an improvement for determining actual building utilization over building operation scheduling according to standard workday profiles, eliminating need for large scale sensor installations. The predicted patterns provide pro-active insights for automatically adjusting building operation modes. For example, the HVAC system output and other services can be reduced or shut down for areas, floors, zones predicted to be low or zero occupancy for specific days and situations.

[0012] Instead of tracking the number of people in the building by sensors, the method according to the disclosed embodiments uses resource consumption data that is always available in building control systems to infer office building occupancy and predict when resources will be needed. There are two additional challenges in inferring occupancy from consumption data, which our proposed method addresses. First, there is tremendous variability across buildings in the types of available consumption meters (e.g., water meters, electrical meters) and how they relate to occupancy. Second, it is difficult to determine which meters are most correlated with occupancy without access to occupancy data (the ground truth).

[0013] FIG. 1 illustrates a framework example of a controller for building energy loads which optimizes a scheduler for energy management in accordance with embodiments of this disclosure. Framework 100 is used to control operations of building load controllers 160, such as cooling, heating and lighting, according to an operations scheduler module 141. In an embodiment, framework 100 includes a meter score engine 121, a prediction engine 131, an operation scheduler 141, and controller interface 151 to provide control instructions to building load controllers 160 for optimized operation modes for the building energy loads correlated to estimates of building occupancy. [0014] Prediction engine 131 is trained to learn occupancy of a building based on patterns extracted from historical data, particularly the consumption data 101 from meters with the highest scores, identified by the meter score engine 121. In an embodiment, the combination of the meter score engine 121 and the Prediction engine 131 may be implemented as a deep learning or a neural network based model.

[0015] FIG. 2 illustrates an example 200 of mapping occupancy to building operation modes according to embodiments of this disclosure. In contrast with commonplace pre-defined operating schedules which do not really fit the actual utilization of the building, an optimized operation mode for energy resources is developed by embodiments of this disclosure according to predicted occupancy periods for the building. For example, operation mode for building energy loads, such as HVAC systems, can be divided into economy mode 211, 215 during hours of predicted low minimal occupancy, reduced mode 212, 214 for time periods with predicted medium occupancy, and full operation mode 213 for predicted maximum occupancy periods, which correspond to regular work hours for a weekday. Accurate prediction could enable closing a floor or section of the building in advance on days of the week that will not be highly occupied, saving energy for large sections of the building. The problem to be solved is that actual historical occupancy data is not easily retrievable for a building to derive accurate predictions. As a solution, the proposed framework relies on consumption meter data for estimating building occupancy during different time period categories such as day of the week, weekend, holiday, and hours of the day. Once a strong (and repeatable) estimation of building occupancy is determined, then the building load controllers 160 can be programmed to a schedule having a profile similar to that shown in FIG. 2 according to the estimated occupancy.

[0016] Returning to FIGI, meter score engine 121 is configured to execute algorithms that extract consumption meter data from data logs and identify the meters most likely to be correlated with building occupancy. In an embodiment, meter score engine determines a meter score for each consumption meter using an algorithm that combines correlations between consumption data of a meter and a set of time series variables including expected occupancy time periods and daily temperature. As an example of expected occupancy time periods for the set of time series variables, the data may be organized by workdays, workhours for the building. This data may be correlated by meter score engine 121 to determine which resource consumption meters are most correlated with occupancy. For each consumption meter, meter score engine 121 combines correlations with temporal data into a single measure that reflects how likely the meter is to predict occupancy. Each resource consumption meter is graded by meter score engine 121 with a meter score derived from a weighted average of correlations between meter consumption data 101 and the time series variables 102. In an embodiment, the meter score engine 121 considers correlations between consumption data of a meter and three time series variables, corresponding to expected work days, expected work hours and historical daily temperature, which can be expressed by the following equation:

Eq.(l) where: y, is meter consumption data for meter j, for j=(l, 2, ... , J); weights are set to be wl = 3, w2 = 1 and w3 =1, but can be selectable (user-specified) for optimal fit to a specific dataset based on temporal patterns; corr_wd is the correlation between consumption data of meter y, and day of week time series variable xl; corr_wh is the correlation between consumption data of meter y, and hour of day time series variable x2; and corr_temp is the correlation between consumption data of meter y, and average outdoor temperature for the day time series variable x3.

A typical building may have as few as J=5 meters and as many as J=1000 meters. Accuracy of meter score engine 121 may be improved by analyzing historical meter consumption data from other buildings in addition to meters installed in the current building being analyzed. Weighting of the correlation with each factor (work days, work hours or temperature) with weights wl, w2, w3 is tunable to a specific building, if a sufficient amount of ground truth occupancy data are available. If that is the case, the weights can be optimized to make a meter score match the true correlation between the meter’s consumption data and the ground truth occupancy data.

[0017] The time series variable xl for workday and x2 for work hours are derived by observing a large dataset for which occupancy data was available and characterizing the types of days and times when office buildings were most occupied. For example, the historical data for a building may indicate that office buildings are more occupied on Tuesdays, Wednesdays and Thursdays than Mondays or Fridays. The data may further indicate that buildings are least occupied on weekends and public holidays, and less occupied on days in between two holidays, compared with days surrounded by other workdays. For cases where historical data is not plentiful or available, the following representative time series for workday variable xl and work hour variable x2 can be used as inputs to Equation 1, in order to identify the meters most likely to be correlated with building occupancy: xl = [0, {holiday, weekend},

0.5 {days in between two holidays}

0.5, {M,F},

1 , {T, W, Th}]

[0018] In terms of work hours, the data may indicate that office buildings are most occupied between 8am and 5pm. For such conditions, an example for the work hour time series can be represented as follows:

^C0rrwork_hours = [1, {0800 < t< 1700};

0, eZse]

Based on the above, an example of time series variables xl , x2 and a meter yi to be correlated may be represented as follows: xl = [ 000.51110.5000.51110.5... 1] (with 365 values for one year of data) x2 = [0000000011111111100000000 00000000111111111. ..0] (with 24 entries for each hour of day, and 365 days of data entries for one year) yi = [ 0.250.50.750.50.5...0.25] (which is consumption reading of meter yi averaged over 24 hours, to get 1 number per day)

[0019] FIG.3 illustrates an example of time series variables xl, x2, x3 and consumption data for a meter y2 which are correlated by meter score engine 121 to determine terms corr_wd, corr_wh and corrtemp for meter score computation according to Eq(l). [0020] Our observations of large datasets indicate that meters that are highly correlated with daily temperature tend to be less correlated with building occupancy, because most of the resource consumption reflects how much energy is needed to heat or cool the building, as opposed to reflecting how many people occupy the building at a given moment. Using this information, meter score engine 121 is configured to compute a higher meter score if the correlation with daily temperature is lower in absolute value (closer to zero). This is reflected in Eq (1) where the meter score is proportional to (1 - absolute value of the correlation with daily temperature). This term will be highest when the correlation with daily temperature is 0, and lowest when the correlation is either 1 or -1. In practice, a meter’s consumption data will be highly positively correlated with temperature if it is related to cooling the building, but highly negatively correlated with temperature if it is related to heating the building.

[0021] Using the meter score formula as shown in Eq.(l), the time series of resource consumption data for each meter in the building is correlated with the workdays, work hours and daily temperature variables, and these three correlations are combined into a single meter score. Each meter score is a value between 0 and 1. The meter score is higher when the resource consumption measured by the meter is positively correlated with workdays and work hours, but less correlated with daily temperature (either positively or negatively).

[0022] Based on ranking of all meter scores, the meters having the highest scores are graded as the “best meters” (i.e., most likely to be correlated with building occupancy) and consequently selected for further analysis. A threshold can be defined (e.g., user-specified and dataset specific) for determining which meters are attributed to the set of best meters.

[0023] To predict occupancy for a given day or time, prediction engine 131 is configured to collect the historical consumption data from the best meters for similar days and times in the past. For instance, to predict the occupancy for a specific Tuesday at 3pm, the work day characteristics are determined, such as workday or holiday, and whether the previous day or next day is a holiday, and historical consumption data is collected for historical days that match these characteristics (e.g., for a target prediction on a Tuesday workday, which is also preceded and followed by work days, historical data is collected for all available Tuesday workdays that are also surrounded by work days). Prediction engine 131 derives an occupancy prediction by calculating the average consumption across the set of best meters for similar Tuesdays in the past. To calculate this average consumption, the consumption data for each of the “best meters” is normalized (e.g., such that the minimal consumption is 0 and the maximal consumption is 1). These normalized values from the best meters are then combined as a weighted average over all the best meters, weighted according to the respective meter scores, to yield the occupancy prediction value (between 0 and 1) for the target time period. In other words, the higher a meter’s score, the greater its contribution to the occupancy prediction value.

[0024] Next, the normalized occupancy prediction value is converted into an estimate of the number of people in the building. For example, the normalized value is denormalized by a scalar value derived from minimum and maximum building occupancy data for the target time period (e.g., for the past year, minimum 10 people and maximum = 300 people). If such hard occupancy data is not available for the target building, the maximum and minimum values can be either estimated or obtained from building manager knowledge.

[0025] Given predictions of building occupancy derived by prediction engine 131 for various time periods (e.g., day of week, workday, weekend, holiday, workhours, etc.), operation scheduler 141 is programmed to control operation modes for the building energy loads with improved correlation to actual building occupancy, rather than rough estimates based on standards of work schedules that have become increasingly fluid. The operation mode schedule is optimized to control energy resource load for energy conservation balanced by comfort and needs of building occupants. For example, heating and cooling loads are scheduled to operate at full capacity for periods of predicted building occupancy and shut down for periods of vacancy. Moreover, operation mode for building energy loads for entire zones and floors can be closed shut off during periods of predicted low occupancy. Controller interface 151 delivers the schedule information to each building load controller 160 (e.g., programmable relays, starters, switches, etc.) configured to directly control energy delivery to the various loads in the building.

[0026] FIG. 4 shows an example of a computer environment within which embodiments of the disclosure may be implemented. A computing device 410 includes a processor 415 and memory 411 (e.g., non-transitory computer readable media) on which various computer applications, modules or executable programs are stored. In an embodiment, memory 411 includes one or more of the following modules: meter score engine module 121, prediction engine module 131, and operation scheduler module 141. [0027] A network 460, such as a local area network (LAN), wide area network (WAN), or an internet based network, connects a remote computing device 441 to modules 121, 131, 141 of computing device 410 to enable remote access computing. Controller interface 151 delivers control schedule information to load controllers 160 via network 460.

[0028] User interface module 414 provides an interface between modules 121, 131, 141 and user interface 430 devices, such as display device 431 and user input device 432. Graphical user interface (GUI) engine 413 drives the display of an interactive user interface on display device 431, allowing a user to receive visualizations of analysis results and assisting user entry of selectable parameters for modules 121, 131, 141.

[0029] Computer readable medium instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0030] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer readable medium instructions.

[0031] The program modules, applications, computer-executable instructions, code, or the like depicted in FIG. 4 as being stored in the system memory 411 are merely illustrative and not exhaustive and that processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by a different module. In addition, various program module(s), script(s), plug-in(s), Application Programming Interface(s) (API(s)), or any other suitable computer-executable code hosted locally on the computer system 410, remote network devices storing modules 441, 442 and/or hosted on other computing device(s) accessible via one or more of the network(s) 460, may be provided to support functionality provided by the program modules, applications, or computer-executable code and/or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of program modules depicted in FIG. 4 may be performed by a fewer or greater number of modules, or functionality described as being supported by any particular module may be supported, at least in part, by another module. In addition, program modules that support the functionality described herein may form part of one or more applications executable across any number of systems or devices in accordance with any suitable computing model such as, for example, a client-server model, a peer-to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 4 may be implemented, at least partially, in hardware and/or firmware across any number of devices.

[0032] It should further be appreciated that the computer system 410 may include alternate and/or additional hardware, software, or firmware components beyond those described or depicted without departing from the scope of the disclosure. More particularly, it should be appreciated that software, firmware, or hardware components depicted as forming part of the computer system 410 are merely illustrative and that some components may not be present or additional components may be provided in various embodiments. While various illustrative program modules have been depicted and described as software modules stored in system memory 411, it should be appreciated that functionality described as being supported by the program modules may be enabled by any combination of hardware, software, and/or firmware. It should further be appreciated that each of the above-mentioned modules may, in various embodiments, represent a logical partitioning of supported functionality. This logical partitioning is depicted for ease of explanation of the functionality and may not be representative of the structure of software, hardware, and/or firmware for implementing the functionality. Accordingly, it should be appreciated that functionality described as being provided by a particular module may, in various embodiments, be provided at least in part by one or more other modules. Further, one or more depicted modules may not be present in certain embodiments, while in other embodiments, additional modules not depicted may be present and may support at least a portion of the described functionality and/or additional functionality. Moreover, while certain modules may be depicted and described as sub-modules of another module, in certain embodiments, such modules may be provided as independent modules or as sub-modules of other modules.

[0033] FIG. 5 shows an example of a computer-implemented method 500 for controlling building energy loads according to building occupancy. A meter score is determined (521) for each of a plurality of consumption meters that measure resource consumption in a building. The meter score is determined by an algorithm that combines correlations between consumption data (101) of a meter and a set of time series variables (102) including expected occupancy time periods and daily temperature. One or more meters are graded as best meters for having the highest meter scores. For some embodiments, the set of time series variables (102) of variables may include (523) a workday variable, a workhour variable, or both. For some embodiments, the meter score may be based (525) on correlation with average daily outdoor temperature for the building. For some embodiments, the meter score may be determined (527) by weighting each regressor correlation with a weight selectable based on temporal patterns.

[0034] An estimation of building occupancy for a time period is determined (531) using a weighted average of normalized consumption data from one or more best meters. For some embodiments, the estimation may be determined by deriving (533) a normalized consumption value for each of the best meters based on historic consumption data of the respective best meters, in which prediction for a target time period is based on consumption data (101) collected for a similar day and time in the past. For some embodiments, the estimation of building occupancy may be determined by deriving (535) a final occupancy prediction value by combining the normalized consumption values of the best meters as a weighted average, with the weighting according to respective meter scores for the best meters, and de-normalizing the weighted average by a scalar value derived from minimum and maximum number of people in the building for the target time period.

[0035] A schedule of operation mode of building energy loads for the target time period is generated (541) based on the estimation of building occupancy. The schedule is optimized for energy conservation.

[0036] The building energy loads are controlled (551) according to the schedule.

[0037] Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and/or processing capabilities described with respect to a particular device or component may be performed by any other device or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure. In addition, it should be appreciated that any operation, element, component, data, or the like described herein as being based on another operation, element, component, data, or the like can be additionally based on one or more other operations, elements, components, data, or the like. Accordingly, the phrase “based on,” or variants thereof, should be interpreted as “based at least in part on.”

[0038] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure, but are not exhaustive or the only possible implementation scheme. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Claims

CLAIMS What is claimed is:

1. A computer based controller for controlling building energy loads according to building occupancy, comprising: a processor (415); and a non-transitory memory (411) having stored thereon modules (121, 131, 141) executed by the processor (415), the modules (121, 131, 141) comprising: a meter score engine (121) configured to determine a meter score for each of a plurality of consumption meters that measure resource consumption in a building, wherein the meter score is determined by an algorithm that combines correlations between consumption data (101) of a meter and a set of time series variables (102) including expected occupancy time periods and daily temperature wherein one or more meters are graded as best meters for having the highest meter scores; a prediction engine (131) configured to estimate building occupancy for a target time period using consumption data (101) from one or more best meters; an operation scheduler (141) configured to generate a schedule of operation mode of building energy loads for the target time period based on the estimation of building occupancy, wherein the schedule is optimized for energy conservation; and a controller (160) configured to control the building energy loads according to the schedule.

2. The system according to claim 1, wherein the set of time series variables includes a workday variable.

3. The system according to any of the claims 1 to 2, wherein the set of time series variables includes a workhour variable.

4. The system according to any of the claims 1 to 3, wherein the meter score is based on correlation with average daily outdoor temperature for the building.

5. The system according to any of the claims 1 to 4, wherein the meter score engine (121) weights each regressor correlation with a weight selectable based on temporal patterns.

6. The system according to any of the claims 1 to 5, wherein the prediction engine (131) is configured to derive a normalized consumption value for each of the best meters based on historic consumption data of the respective best meters, wherein prediction for a target time period is based on consumption data collected for a similar day and time in the past.

7. The system according to claim 6, wherein the prediction engine (131) is configured to derive a final occupancy prediction value by: combining the normalized consumption values of the best meters as a weighted average, with the weighting according to respective meter scores for the best meters, and de-normalizing the weighted average by a scalar value derived from minimum and maximum number of people in the building for the target time period.

8. The system according to any of the claims 1 to 7 wherein the consumption meters comprise electricity meters, natural gas meters, and water meters installed in the building.

9. A computer-implemented method for controlling building energy loads according to building occupancy, comprising: determining (521) a meter score for each of a plurality of consumption meters that measure resource consumption in a building, wherein the meter score is determined by an algorithm that combines correlations between consumption data (101) of a meter and a set of time series variables (102) including expected occupancy time periods and daily temperature, wherein one or more meters are graded as best meters for having the highest meter scores; determining (531) an estimation of building occupancy for a time period using a weighted average of normalized consumption data from one or more best meters; generating (541) a schedule of operation mode of building energy loads for the target time period based on the estimation of building occupancy, wherein the schedule is optimized for energy conservation; and controlling (551) the building energy loads according to the schedule.

10. The method of claim 9, wherein the set of time series variables (102) of variables includes a workday variable (523).

11. The method according to any of the claims 9 to 10, wherein the set of time series variables (102) includes a workhour variable (523).

12. The method according to any of the claims 9 to 11, wherein the meter score is based (525) on correlation with average daily outdoor temperature for the building.

13. The method according to any of the claims 9 to 12, wherein determining the meter score includes weighting (527) each regressor correlation with a weight selectable based on temporal patterns.

14. The method according to any of the claims 9 to 13, wherein determining the estimation of building occupancy includes deriving (533) a normalized consumption value for each of the best meters based on historic consumption data of the respective best meters, wherein prediction for a target time period is based on consumption data (101) collected for a similar day and time in the past.

15. The method according to claim 14, wherein determining the estimation of building occupancy includes deriving (535) a final occupancy prediction value by: combining the normalized consumption values of the best meters as a weighted average, with the weighting according to respective meter scores for the best meters, and de-normalizing the weighted average by a scalar value derived from minimum and maximum number of people in the building for the target time period.