HEATING CONTROL SYSTEM

Abstract

A heating control system is provided for a multi-occupancy building. The heating control system uses a plurality of mobile devices, for example mobile telephones or tablet computers, which connect to a multiple-access-point wireless data network within the building. The wireless access points provide a controller with details of devices connected to each access point, so that occupancy of each heating zone can be estimated. The mobile devices can be used by occupants to send messages to the controller requesting increases or decreases in temperature. In this way, the temperature of heating zones within the building may be regulated taking into account the preferences of all occupants.

Claims

1. A temperature control system for a multi-occupancy building, the temperature control system comprising: a plurality of temperature sensors for measuring the temperature of heating/cooling zones within the building; means for controlling heating and/or cooling means within the heating/cooling zones; a plurality of wireless data network access points within the building, forming a wireless data network within the building; at least one mobile device, being associated with a building occupant, and each mobile device being connectable to the wireless data network; a controller connected to the data network, in which the wireless data network access points are adapted to provide information to the controller as to the mobile devices present within each heating/cooling, zone, the temperature sensors are adapted to provide information to the controller as to the temperature in each heating/cooling zone, and each of the at least one mobile device is adapted to be provided with a user interface through which a building occupant can provide a temperature preference to the controller, the controller operating the means for controlling heating and/or cooling means to regulate the temperature in each heating/cooling zone based on the current temperature and; the temperature preference received from each mobile device of the at least one mobile device, wherein a machine-readable token is provided in each heating/cooling zone, wherein the machine-readable token specifies a website address that leads to a unique page of the user interface, and wherein the user interface identifies the heating/cooling zone of the machine-readable token.

2. A temperature control system as claimed in claim 1, in which the wireless data network access points are adapted to provide identifiers associated with connected mobile devices to the controller.

3. A temperature control system as claimed in claim 1, in which the wireless data network access points are adapted to provide a count of the number of connected mobile devices to the controller.

4. A temperature control system as claimed in claim 1, in which the temperature sensors are connected to the data network.

5. A temperature control system as claimed in claim 1, in which the means for controlling the heating and/or cooling means are connected to the data network.

6. A temperature control system as claimed in claim 1, in which the controller operates the means for controlling the heating and/or cooling means to regulate the temperature in each heating/cooling, according to a temperature setpoint associated with each heating/cooling, the temperature setpoint for a particular zone at a particular time being determined based on at least the number of mobile devices present in the zone, the number of messages received from mobile devices in the zone requesting that the temperature is increased and the number of messages received from mobile devices in the zone requesting that the temperature is decreased.

7. A temperature control system as claimed in claim 6, in which the controller regulates the temperature in each heating/cooling zone further based on information from an electronic room booking database or electronic calendar.

8. A temperature control system as claimed in claim 7, in which the setpoint is determined further based on information from an electronic room booking database or electronic calendar.

9. A temperature control system as claimed in claim 1, in which the controller regulates the temperature in each heating/cooling zone further based on a heating/cooling profile for the heating/cooling zone.

10. A temperature control system as claimed in claim 9, in which the controller is adapted to update the heating/cooling profile using measurements from the temperature sensors, according to a machine learning algorithm.

11. (canceled)

12. A temperature control system as claimed in claim 1, in which the machine-readable token is a

13. A temperature control system as claimed in claim 1, in which the machine-readable token is an RFID or NFC tag.

14. A temperature control system as claimed in claim 1, wherein the at least one mobile device comprises a plurality of mobile devices, wherein the controller is configured to receive user temperature preferences from each mobile device of the plurality of mobile devices, and wherein the controller applies a voting algorithm to determine a set temperature for a heating/cooling zone, with each received temperature preference is a vote used by the voting algorithm.

15. A temperature control system as claimed in claim 2, wherein the controller operating the means for controlling heating and/or cooling means to regulate the temperature in each heating/cooling zone is further based on the number of mobile devices present in the zone.

16. A temperature control system as claimed in claim 1, wherein the system stores personal temperature setting preferences of building occupants associated with the number of mobile devices present in a heating/cooling zone, and when a user arrives to the heating/cooling zone, the system recognises the presence of the user and automatically casts a vote on behalf of the user according to the stored personal temperature setting preference.

17. A temperature control system as claimed in claim 9, wherein the controller is adapted to create the heating/cooling profile by analysing historical data on heating/cooling zones using a machine learning algorithm to identify the time needed to reach a target temperature from a current temperature for each zone.

18. A temperature control system as claimed in claim 9, wherein the controller is adapted to monitor real-time occupancy of individual zones in the multi-occupancy building, wherein historical data is combined with real-time occupancy data to feed a machine learning algorithm to identify occupancy patterns to predict the occupancy of the heating/cooling zones, and wherein the controller is adapted to change the occupancy status of a room based on the occupancy prediction and trigger a change in temperature setting.

19. A temperature control system as claimed in claim 12, wherein the machine-readable optical label is a QR code.

Description

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENT

[0027] For a better understanding of the invention and to show more clearly how it may be carried into effect, an example embodiment will now be described with reference to drawings.

[0028] The Process

[0029] An automatic decision-making process which determines the desirable temperature value in an individual (heating/cooling) zone based on different input parameters (FIG. 1). After decision making, the system sets the status of a zone, triggering a change in temperature setting (output) This output can be used as an input for temperature control (e.g. changing valve status, thermostat settings etc. over time). The system can manage and control large number or even unlimited zones in parallel therefore suitable for commercial buildings like hotels, hospitals, office buildings etc.

[0030] See FIG. 1.

[0031] Process Elements:

[0032] 1. Decision Making

[0033] 1.1. Zone Status and Temperature Settings

[0034] The system's decision-making module can change the status of the room (e.g. in case of a meeting room the status can be changed from ‘booked’ to ‘not booked’), triggering changes in the temperature setting and starting heating/cooling actions. The decision-making model can be applied to any zones using several inputs and preferences that are listed and explained in the following sections (FIG. 2).

[0035] See FIG. 2.

[0036] In case of the presence of several inputs in the system, the inputs are collected in different categories then the hierarchy of the different input categories can be defined (see Input 8 for detailed description). According to this hierarchy, the system can prioritize between process inputs and uses the most relevant one for decision making. In this way, default and default/custom scheduling (Input 1), data from any room booking systems (Input 2), manual user input via QR codes (Input 3), occupancy detection and prediction (Input 4), voting (Input 5), and the use of stored user preferences (Input 6) can be prioritized and used according to the defined preferences (Input 8).

[0037] When there is no active input, the temperature settings of zones return to their default status, defined by Input 1 and Input 8.

[0038] Summary: The decision-making step considers all the system inputs to define the heating/cooling actions to be performed at each time in each room.

[0039] 1.2. Timing (Optimisation Module)

[0040] The hierarchy of inputs is used to prioritize between process inputs and to ensure that every zone of the building has the right temperature settings. As each zone's energy demand and response time is different in case of a change in temperature settings, an optimisation algorithm is also used to determine the optimal timing to start increasing, decreasing, turn on and off the heating/cooling devices.

[0041] The optimisation algorithm is used to ensure that any zone temperatures are the same as set temperatures e.g. by the time a meeting is about to start. The optimisation algorithm is also used to optimise the energy demand of the zones when changing temperature settings (e.g. making a decision if the energy consumption of a zone is better when the temperature setting goes into default between two meetings or if it stays unchanged.

[0042] This optimization step uses information like the heating/cooling profile of the zones (see also Input 7) in order to determine the amount of time needed for a zone to reach the set temperature determined by the decision-making process.

[0043] Summary: An optimization process is used to maximize the user comfort (according to users' set temperatures) and minimize the energy costs, using the data from the several inputs and the most updated room heating/cooling profiles.

[0044] 1.3. Preferences and Predictions Module

[0045] The stored user preferences are either used as an individual input (see Input 6) or to cast automatic votes when users' presence is detected (see Input 5).

[0046] The decision-making process can also change the status of a zone e.g. when it is expected that a user will be in the room (through occupancy prediction, see Input 4) e.g. from “unoccupied” to “occupied”.

[0047] 2. Process Inputs

[0048] The following points describe the different process inputs of the decision-making algorithm, determining the output (temperature settings) for each individual zones. The minimum requirement for the proper operation of the system is to have at least one Input (e.g. a default parameter defined by Input 1).

[0049] All Inputs are optional but increasing the number of Inputs increases the sophistication of temperature control and improves system behaviour with the added value of increased user satisfaction and reduced energy consumption of the buildings.

[0050] 2.1. Input 1: Facilities Manager Interface

[0051] A “Facilities Manager Interface” is a graphical user interface where the responsible person of the building/facility sets up basic settings for the entire “system”. These parameters determine the core and the basic behaviour of the “system” without any further intervention (without further inputs). The basic parameters can be determined before activating the “system” or while the system is running.

[0052] The main settings on the “Facilities Manager Interface”: [0053] a. “Zone type”: Determines the type of the individual heating/cooling zones. Facilities manager could choose from different predefined types (ie: shop, meeting room, shared office accommodation, etc.).  There could be single use (ie: private office, accommodation room, etc.) and multi-use (ie: seminar room, meeting room, shared office, communal area, etc.) zones. User of a single use zone could directly modify the temperature setting via the user interface between the certain limits the FM determined (Tmin-Tmax). In case of multi-use zone, the users can vote via the user interface and the voting algorithm determines the best-optimal temperature value based on the different votes (see: input 5 and input 6). [0054] b. “Status”: Each zone can have different statuses. The zone status can change, depending on occupancy and usage. Zones can be out of use e.g. because of renovation (status is ‘long term inactive’), occupied (‘active’) temporarily unoccupied (‘temporarily away’) etc. depending on usage. Zone statuses have predefined parameters (see table x). Zone status can change several times during the day, triggering changes in the temperature settings. [0055] c. T default: Determines the default temperature value for the different room statuses. [0056] d. T min: Determines the minimum temperature value what a user can set. [0057] e. T max: Determines the maximum temperature value what a user can set. [0058] f. Longevity of user votes for zones with multiple users with “voting feature (Input 5) enabled [0059] g. Hierarchy of different system Inputs  Table 1 shows an example for parameters of point a-e:

TABLE-US-00001 TABLE 1 T.sub.default T.sub.min T.sub.max Zone type Status (° C.) (° C.) (° C.) accommodation occupied active 21 15 23 occupied inactive 16 — — (temporarily away) occupied night 19 15 21 not in use (long 10 — — term inactive) shared offices occupied active 21 18 22 occupied inactive 19 15 21 (temporarily away) not in use (long 10 — — term inactive) private office occupied active 21 18 22 occupied inactive 19 15 21 (temporarily away) not in use (long 10 — — term inactive) museum/shop/ open 20 — — café close 16 — — [0060] h. Scheduling: Facilities Manager can allocate a schedule for the different zones with a schedule automatically changing the status of the room following the settings. (E.g. changing from “open” status to “closed” status in case of a zone defined as “museum”.) The different statuses of the zones have predefined temperature settings—see c, d and e). [0061] i. As part of the graphical interface, Facilities Managers can define the details of a default schedule (ie: “open” status is defined as Monday-Saturday, from 7 am until 10 pm. morning at 10 am, the zone 1 (ie: museum) is OPEN. (See Table 2 as example). The settings of the default schedule can be modified by Facilities Manager.

TABLE-US-00002 TABLE 2 Default Schedule Zone type Status Days start end accommodation occupied active Mo, Tu, We, 7 am 10 pm Th, F, Sa, Su occupied inactive — — — (temporarily away) occupied night Mo, Tu, We, 10 pm 7 am Th, F, Sa, Su not in use (long — — — term inactive) Hallways active Mo, Tu, We, 7 am 8 pm Th, F inactive Mo, Tu, We, 8 pm 7 am Th not in use (long F 8 pm 0 am term inactive) Sa, Su 0 am 12 pm museum/shop/ open (1) Mo, Tu, We, 9 am 5 pm café Th, F open (2) Sa 9 am 3 pm close rest of the time [0062] ii. Custom/Manual Schedule: Facilities Manager can modify the pre-set default schedule any time for specific dates or zones. Outside of the manually specified dates, the default schedule settings will still apply (ie.: during a holiday period Zone 1 defined as ‘Museum’ can have a different opening time than usual. Changes in zone status will follow the custom schedule on the specific dates then returns to the default schedule after.)

[0063] If the system is capable to detect non-desirable events (ie: open window, malfunction of the heat exchanger, etc.), it can automatically send notifications for the corresponsive person(s) (e.g. Facilities Manager) or act automatically to correct the non-desirable event.

[0064] 2.2. Input 2: Room Booking System

[0065] Commercial buildings often use resource booking tools for space management and room booking. These are either cloud based or local software solutions. The software can be commissioned by the institute or purchased like PlanOn, MICAD, Kinetics Solutions etc. from a software provider. Institutes also often use shared calendars like Google Calendar, Microsoft Exchange calendars, Outlook for space management.

[0066] Professional space management softwares often use SQL databases with a browser-enabled room booking front-end.

[0067] With occupancy information already in the room booking system in use, the room booking data can be used as an input for heating/cooling control (room booking-temperature control).

[0068] With a custom-made built in API (API 1), the system pulls data directly from the primary data source of the existing room booking system through an API (API 2). Data can be also pushed instead of pulling, (from API 2 to API 1) according to the preferences of the facilities management.

[0069] API 1 uses the protocol specified by API 2 and system's cloud ensures that room availability (occupancy status) is updated in real time.

[0070] An API (ie. API 2) can be commissioned from and set up by the software provider. When this is not an option, EcoSync develops a custom made, local API (ie. API 2), after receiving secured access to the data source and documentation.

[0071] After developing or installing a API 2, the room booking systems can automatically send all information required to update system's cloud-based database. (AKA push data from API 2 to API 1.)

[0072] In those cases when an API solution is not available, the room booking information can be manually exported and imported into the system's database in a number of digital formats (eg. MS Excel Spreadsheets).

SUMMARY

[0073] Using the primary data source of the existing cloud based or local room booking software of the buildings, system has room availability and occupancy information updated in real time, used as an input for decision making.

[0074] Example for API for Planon room booking system integration: https://github.com/mhvis/planon

[0075] 2.3. Input 3: User Interface with QR Code Access

[0076] Each zone have individual and unique URLs and corresponding QR codes displayed in the zone, designed for easy access with a mobile device or computer. The web address specified by the QR code/URL leads to a unique page of the user interface. This user interface provides easy access to temperature settings/voting for users without installing any applications but identifies the exact location (zone) of the user.

[0077] User(s) can reach the User Interface by typing the URL code into an internet browser, or by scanning a two-dimensional barcode (QR code) with a mobile device.

[0078] See FIG. 3.

[0079] The User Interface can display relevant information (e.g. the zone and current temperature setting or real time temperature) with the option for user to modify it within a temperature defined by Facilities Managers (See also Input 1). Based on the zone type (e.g. shared office or a private office) the user preference is directly translated as an Input (e.g. in case of a private office or accommodation type of zone—see also Input 1, point d-e) or is taken into account as a “vote” (see Input 3). This is relevant in multi-users zones like shared offices, meeting rooms etc. (FIG. 4)

[0080] Instead of QR codes other machine-readable optical labels can be also used to provide URL for instant access.

[0081] See FIG. 4.

[0082] 2.4. Input 4: Real-time Occupancy Detection

[0083] User occupancy along the building or in individual zones can be determined or estimated in real time through presence detection counters, sensors or the existing Wi-Fi network of the building. (e.g. data from the access points, access point controllers or the dashboard of the Wi-Fi system registering the Wi-Fi enabled devices connected to different access points used to estimate the number of users.

[0084] For more accurate location identification (indoor positioning) a triangulation technique can be also used.

[0085] The real-time occupancy detection is used for two purposes: [0086] a. Change the status of the room automatically. E.g. if unexpected user presence is detected in a zone previously determined as “unoccupied”, the input can be used to change the room status to “occupied”, so the status and the temperature settings can be adjusted accordingly. The same occupancy detection can be used for security purposes—e.g. a zone defined as ‘Museum’ receiving an input/request suggesting that the zone is occupied while scheduled to be “closed” can trigger a notification about the presence of an unauthorised person. [0087] b. Monitor occupancy patterns for prediction purposes. The historical data on each room's occupancy is combined with the occupancy data acquired in real-time in order to feed a machine learning algorithm that identifies occupancy patterns. Occupancy patterns of the zones can be used to predict occupancy and change the status of the zones.

[0088] Real-time or historical data, like Input 2, can be pulled, pushed or manually exported.

[0089] Summary: Real-time detection of occupancy in each room is used to manage rooms' heating/cooling management settings and for occupancy patterns prediction purposes.

[0090] 2.5. Input 5: Voting

[0091] Traditional thermostats in case of multiple user access cannot distinguish between inputs and the last temperature setting automatically overwrites the settings of the previous users, creating tensions between co-workers sharing offices and other zones.

[0092] Multi-user zones (e.g. shared offices, meeting rooms etc.) can receive several temperature change requests via the User Interface. To select the ideal output (temperature setting) for a zone occupied by multiple users, the voting algorithm uses a parameterized background algorithm inside the system. The algorithm uses individual user temperature preferences to determine the most suitable set temperature for the zone (ie. vote received via the User Interface point 3). Votes can be averaged, weighted, normalised by the total number of people in the zone (see Input 4) etc.

[0093] The parameters of the algorithm are the following: [0094] a. Operating times of zones, scheduling (point 1.i.) [0095] b. Default, Minimum, Maximum available temperatures (set in point 1.b-d.) [0096] c. Individual user temperature preferences (votes) received via the User Interface [0097] d. Longevity of votes, the length of time a vote has effect from the time of casting it. [0098] e. Mathematical function (aka. graph) that has the number of users present (eg. x axis of the graph) in the zone (occupancy detection —see Input 4 point 4) and the amount of active voters (eg. y axis of the graph) as input and on it's output (eg. z axis) the new temperature setting that the voting will cause. eg. a possible function: fn(x,y)=T min+(T max−T min)*(O.sub.active/O.sub.present)

[0099] 2.6. Input 6: Remembering User Temperature Preferences

[0100] The personal temperature setting preference of a user (for specific zones or in general) can be stored in the system. When a user arrives to a zone the system recognises their presence and casts a vote in behalf of them automatically according to their previously set preferences.

[0101] In case if the local regulations are not allowing to store any user data in the system because of personal-individual rights, then it is possible that the system only links the identifier number of the device itself (ie: IP or MAC address), which the user used to change her/his preference, with the preferred temperature setting.

[0102] 2.7. Input 7: Adaptive Room Heating/Cooling

[0103] Historical data on zones e.g. actual temperature of the zone, external temperature, heating control (valve statuses) etc are analysed by a machine learning algorithm, which identifies the time needed to reach a target temperature from the current temperature in each room, considering each current situation. The algorithm is used to create a unique and adaptive heating/cooling profile for each zone; The room heating/cooling profile can be continuously updated by being fed by the real-time acquired data (sensor data, inputs, third party information etc). In this way, the heating/cooling profiles of the zones are adaptive to changes in the environment (e.g. change of room conditions, such as a window being open or closed; the installation of a new, more energy efficient window; or the change in users' habits by leaving the doors between different rooms open or closed more often—causing a significant impact in the heating/cooling profile of the zone.)

[0104] Information gained from the heating/cooling profile of zones can be used as Input 7 and fine-tune the direct temperature setting requests coming from Input 1-6.

[0105] Summary: The adaptive room heating/cooling algorithm identifies the time needed to reach a target temperature in each zone.

[0106] 2.8. Input 8: Hierarchy

[0107] With several optional Inputs, the system needs to determine which input to take into account when more options are available.

[0108] For example a private office could be set up by the “Facilities Manager” as a zone active (in use) on weekdays from 9 am to 5 pm while the actual user of the office might have differences—e.g. working from 8 am to 4 pm on certain days and away other days. This means contradicting status for the zone from the Default Schedule of the Facilities Manager, User Interface, Occupancy Detection, Prediction etc.

[0109] A pre-set hierarchy of the available and enabled Inputs can be pre-defined by Facilities Manager via the graphic user interface and modified later (See also Input 1g)

[0110] The hierarchy defines which inputs are active for a specific zone and what is their order in case of several inputs. The input set higher in the hierarchy will define the status of the zone therefore its temperature settings.

[0111] The invention provides a heating control system for a multi-occupancy building. The heating control system uses a plurality of mobile devices, for example mobile telephones or tablet computers, which connect to a multiple-access-point wireless data network within the building. The wireless access points provide a controller with details of devices connected to each access point, so that occupancy of each heating zone can be estimated. The mobile devices can be used by occupants to send messages to the controller requesting increases or decreases in temperature.

[0112] In this way, the temperature of heating zones within the building may be regulated taking into account the preferences of all occupants.

[0113] The description of this embodiment is given as an example only. Variations and modifications will be apparent to the skilled person, within the scope of the invention. The invention is defined in the claims.