WATER HEATER MONITORING

Abstract

In one aspect, a first device includes a processor and storage accessible to the processor. The storage bears instructions executable by the processor to receive input from a water heater meter that monitors a water heater and provide an output comprising information pertaining to a time estimate related to the provisioning of heated water based on the input.

Description

FIELD

The present application relates generally to water heater monitoring.

BACKGROUND

As recognized herein, a water heater may be able to provide but a limited amount of hot water during a particular time span. As also recognized herein, there may be instances where multiple people or items in a buldding are to use hot water from the water heater, and there are currently no adequate ways for determining whether the water heater is able to provide enough hot water to meet the demands of the people and/or items.

SUMMARY

Accordingly, in one aspect a first device includes a processor and storage accessible to the processor. The storage bears instructions executable by the processor to receive input from a water heater meter that monitors a water heater and provide an output comprising information pertaining to a time estimate related to the provisioning of heated water based on the input.

In another aspect, a method includes receiving input from a water heater meter that monitors a water heater and, based on the input, presenting an output pertaining to a time at which water from the water heater will be ready for use to engage in a particular activity.

In still another aspect, a water heating device includes a water heater, a water tank that holds water heated by the water heater, a processor, a network transceiver accessible to the processor, a sensor accessible to the processor and that monitors water in the water tank, and storage. The storage bears instructions executable by the processor to receive input from the sensor. The instructions are also executable by the processor to, based on the input, provide data to another device using the network transceiver. The data pertains to whether the water heating device holds enough hot water to supply hot water throughout performance of a particular activity.

In yet another aspect, a method includes receiving input from a water heater meter that monitors a water heater and providing an output comprising information pertaining to a time estimate related to the provisioning of heated water based on the input.

The details of present principles, both as to their structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example system in accordance with present principles;

FIG. 2 is a block diagram of a network of devices in accordance with present principles;

FIGS. 3-5 are flow charts of example algorithms in accordance with present principles;

FIGS. 6 and 7 are example data tables in accordance with present principles; and

FIGS. 8-11 are example user interfaces (UI) in accordance with present principles.

DETAILED DESCRIPTION

With respect to any computer systems discussed herein, a system may include server and client components, connected over a network such that data may be exchanged between the client and server components. The client components may include one or more computing devices including televisions (e.g., smart TVs, Internet-enabled TVs), computers such as desktops, laptops and tablet computers, so-called convertible devices (e.g., having a tablet configuration and laptop configuration), and other mobile devices including smart phones. These client devices may employ, as non-limiting examples, operating systems from Apple, Google, or Microsoft. A Unix or similar such as Linux operating system may be used. These operating systems can execute one or more browsers such us a browser made by Microsoft or Google or Mozilla or other browser program that can access web applications hosted by the Internet servers over a network such as the Internet, a local intranet, or a virtual private network.

As used herein, instructions refer to computer-implemented steps for processing information in the system. Instructions can be implemented in software, firmware or hardware; hence, illustrative components, blocks, modules, circuits, and steps are set forth in terms of their functionality.

A processor may be any conventional general purpose single- or multi-chip processor that can execute logic by means of various lines such as address lines, data lines, and control lines and registers and shift registers. Moreover, any logical blocks, modules, and circuits described herein can be implemented or performed, in addition to a general purpose processor, in or by a digital signal processor (DSP), a field programmable gate array (FPGA) or other programmable logic device such as an application specific integrated circuit (ASIC), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor can be implemented by a controller or state machine or a combination of computing devices.

Any software and/or applications described by way of flow charts and/or user interfaces herein can include various sub-routines, procedures, etc. It is to be understood that logic divulged as being executed by, e.g., a module can be redistributed to other software modules and/or combined together in a single module and/or made available in a shareable library.

Logic when implemented in software, can be written in an appropriate language such as but not limited to C# or C++, and can be stored on or transmitted through a computer-readable storage medium (e.g., that is not a transitory signal) such as a random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disk read-only memory (CD-ROM) or other optical disk storage such as digital versatile disc (DVD), magnetic disk storage or other magnetic storage devices including removable thumb drives, etc.

In an example, a processor can access information over its input lines from data storage, such as the computer readable storage medium, and/or the processor can access information wirelessly from an Internet server by activating a wireless transceiver to send and receive data. Data typically is converted from analog signals to digital by circuitry between the antenna and the registers of the processor when being received and from digital to analog when being transmitted. The processor then processes the data through its shift registers to output calculated data on output lines, for presentation of the calculated data on the device.

Components included in one embodiment can be used in other embodiments in any appropriate combination. For example, any of the various components described herein and/or depicted in the Figures may be combined, interchanged or excluded from other embodiments.

The term “circuit” or “circuitry” may be used in the summary, description, and/or claims. As is well known in the art, the term “circuitry” includes all levels of available integration, e.g., from discrete logic circuits to the highest level of circuit integration such as VLSI, and includes programmable logic components programmed to perform the functions of an embodiment as well as general-purpose or special-purpose processors programmed with instructions to perform those functions.

Now specifically in reference to FIG. 1, an example block diagram of an information handling system and/or computer system 100 is shown. Note that in some embodiments the system 100 may be a desktop computer system, such as one of the ThinkCentre® or ThinkPad® series of personal computers sold by Lenovo (US) Inc. of Morrisville, N.C., or a workstation computer, such as the Think Station®, which are sold by Lenovo (US) Inc. of Morrisville, N.C.; however, as apparent from the description herein, a client device, a server or other machine in accordance with present principles may include other features or only some of the features of the system 100. Also, the system 100 may be, e.g., a game console such as XBOX® or Playstation®, and/or the system 100 may include a wireless telephone, notebook computer, and/or other portable computerized device.

As shown in FIG. 1, the system 100 may include a so-called chipset 110. A chipset refers to a group of integrated circuits, or chips, that are designed to work together. Chipsets are usually marketed as a single product (e.g., consider chipsets marketed under the brands INTEL®, AMD®, etc.).

In the example of Figure 1, the chipset 110 has a particular architecture, which may vary to some extent depending on brand or manufacturer. The architecture of the chipset 110 includes a core and memory control group 120 and an I/O controller hub 150 that exchange information (e.g., data, signals, commands, etc.) via, for example, a direct management interface or direct media interface (DMI) 142 or a link controller 144. In the example of FIG. 1, the DMI 142 is a chip-to-chip interface (sometimes referred to as being a link between a “northbridge” and a “southbridge”).

The core and memory control group 120 include one or more processors 122 (e.g., single core or multi-core, etc.) and a memory controller hub 126 that exchange information via a front side bus (FSB) 124. As described herein, various components of the core and memory control group 120 may be integrated onto a single processor die, for example, to make a chip that supplants the conventional “northbridge” style architecture.

The memory controller hub 126 interfaces with memory 140. For example, the memory controller hub 126 may provide support for DDR SDRAM memory (e.g., DDR, DDR2, DDR3, etc.). In general, the memory 140 is a type of random-access memory (RAM). It is often referred to as “system memory.”

The memory controller hub 126 can further include a low-voltage differential signaling interface (LVDS) 132. The LVDS 132 may be a so-called LVDS Display Interface (LDI) for support of a display device 192 (e.g., a CRT, a flat panel, a projector, a touch-enabled display, etc.). A block 138 includes some examples of technologies that may be supported via the LVDS interface 132 (e.g., serial digital video, HDMI/DVI, display port). The memory controller hub 126 also includes one or more PCI-express interfaces (PCI-E) 134. for example, for support of discrete graphics 136. Discrete graphics using a PCI-E interface has become an alternative approach to an accelerated graphics port (AGP). For example, the memory controller hub 126 may include a 16-lane (x16) PCI-E port for an external PCI-E-based graphics card (including, e.g., one of more GPUs). An example system may include AGP or PCI-E for support of graphics.

In examples in which it is used, the I/O hub controller 150 can include a variety of interfaces. The example of FIG. 1 includes a SATA interface 151, one or more PCI-E interfaces 152 (optionally one or more legacy PCI interfaces), one or more USB interfaces 153, a LAN interface 154 (more generally a network interface for communication over at least one network such as the Internet, a WAN, a LAN, etc. under direction of the processors) 122), a general purpose I/O interface (GPIO) 155, a low-pin count (LPC) interface 170, a power management interface 161, a clock generator interface 162, an audio interface 163 (e.g., for speakers 194 to output audio), a total cost of operation (TCO) interface 164, a system management bus interface (e.g., a multi-master serial computer bus interface) 165, and a serial peripheral flash memory/controller interface (SPI Flash) 166, which, in the example of FIG. 1, includes BIOS 168 and boot code 190. With respect to network connections, the I/O hub controller 150 may include integrated gigabit Ethernet controller lines multiplexed with a PCI-E interface port. Other network features may operate independent of a PCI-E interface.

The interfaces of the I/O hub controller 150 may provide for communication with various devices, networks, etc. For example, where used, the SATA interface 151 provides for reading, writing or reading and writing information on one or more drives 180 such as HDDs, SDDs or a combination thereof, but in any case the drives 180 are understood to be, e.g., tangible computer readable storage mediums that are not transitory signals. The I/O hub controller 150 may also include an advanced host controller interface (AHCI) to support one or more drives 180. The PCI-E interface 152 allows for wireless connections 182 to devices, networks, etc. The USB interface 153 provides for input devices 184 such as keyboards (KB), mice and various other devices (e.g., cameras, phones, storage, media players, etc.).

In the example of FIG. 1, the LPC interface 170 provides tor use of one or more ASICs 171, a trusted platform module (TPM) 172, a super I/O 173, a firmware hub 174, BIOS support 175 as well as various types of memory 176 such as ROM 177, Flash 178, and non-volatile RAM (NVRAM) 179. With respect to the TPM 172, this module may be in the form of a chip that can be used to authenticate software and hardware devices. For example, a TPM may be capable of performing platform authentication and may be used to verify that a system seeking access is the expected system.

The system 100, upon power on, may be configured to execute boot code 190 for the BIOS 168, as stored within the SPI Flash 166, and thereafter processes data under the control of one or more operating systems and application software (e.g., stored in system memory 140). An operating system may be stored in any of a variety of locations and accessed, for example, according to instructions of the BIOS 168.

Additionally, though now shown for clarity, in some embodiments the system 100 may include a gyroscope that senses and/or measures the orientation of the system 100 and provides input related thereto to the processor 122, an accelcrometer that senses acceleration and or movement of the system 100 and provides input related thereto to the processor 122, an audio receiver/microphone that provides input to the processor 122 based on audio that is detected, such as via a user providing audible input to the microphone, and a camera that gathers one or more images and provides input related thereto to the processor 122. The camera may be a thermal imaging camera, a digital camera such as a webcam, a three-dimensional (3D) camera, and/or a camera otherwise integrated into the system 100 and controllable by the processor 122 to gather pictures/images and/or video. Still further, and also not shown for clarity, the system 100 may include a GPS transceiver that is configured to receive geographic position information from at least one satellite and provide the information to the processor 122. However, it is to be understood that another suitable position receiver other than a GPS receiver may be used in accordance with present principles to determine the location of the system 100.

It is to be understood that an example client device or other machine/computer may include fewer or more features than shown on the system 100 of FIG. 1. In any case, it is to be understood at least based on the foregoing that the system 100 is configured to undertake present principles.

Turning now to FIG. 2, example devices are shown communicating over a network 200 such as the Internet in accordance with present principles. It is to be understood that each of the devices described in reference to FIG. 2 may include at least some of the features, components, and/or elements of the system 100 described above.

FIG. 2 shows a notebook computer and/or convertible computer 202, a desktop computer 204, a wearable device 206 such as a smart watch, a smart television (TV) 208, a smart phone 210, a tablet computer 212, a water heating device/water heater 216, and a server 214 such as an Internet server that may provide cloud storage accessible to the devices 202-212 and 216. It is to be understood that the devices 202-216 are configured to communicate with each other over the network 200 to undertake present principles.

Describing the water heating device 216 in more detail, it may include a tank 218 tor holding water heated by a water heater 220. The device 216 may also include one or more sensors and/or meters 222 for measuring/sensing various parameters related to the device 216, such as an amount of water being held in the tank 218, a temperature of that water, a rate of consumption of that water by other items fluidly connected to the device 216 (such as a shower in the same building as the device 216 is disposed), etc. The sensors) 222 may thus provide input to the at least one processor 224 on the device 216 regarding these parameters, and that input may be processed by the processor 224, as well as stored in storage 226 accessible to the processor 224 and/or remotely at other storage areas accessible to the processor 224 using the network transceiver/interface 228. It is to thus be understood that the processor 224 controls the network interface 228 to communicate with other devices such as those in the network 200.

Before moving on in the detailed description, it is to be understood that a water meter, as referenced herein, may refer collectively to sensors, processors, storage, and network interfaces (and still other computing components) such as the elements 222-228 described above, while in some instances it may also refer specifically to sensors such as the sensor 222 described above.

Now referring to FIG. 3, it shows example logic that may be executed by a device such as the water heating device/water heater 216 in accordance with present principles (referred to below when describing FIG. 3 as the “present device”). Beginning at block 300, the logic may receive input from one or more sensors on the present device, such as the sensor(s) 222 described above. Responsive to receipt of input from the sensor(s), the logic may proceed to block 302 where the logic processes the input to identify an amount of (e.g., hot) water currently being housed in the present device and/or level of that water. At block 302, the logic may also identify other parameters and/or characteristics as described herein based on the type of input received from the sensor(s), such as a temperature of the water, a rate of consumption of the water and/or a flow rate of the water out of the present device, etc.

From block 302 the logic of FIG. 3 may next proceed to block 304. At block 304, based on the input that is received and/or processed, the logic may provide data at the present device, such as on a touch-enabled display disposed on the present device and accessible to the processor undertaking the logic of FIG. 3, pertaining to the amount and/or level of water in the present device, the temperature of the water, etc. Also at block 304, the logic may transmit the data to and/or present the data on another device with which the present device communicates, such as a user's smart phone or a display in another part of the building in which the present device is disposed.

Reference is now made to FIG. 4, which shows example logic that may be executed by a device such as the system 100 in accordance with present principles, such as when receiving data from a device undertaking the logic of FIG. 3 described above. Beginning at block 400, the logic may receive and/or process input from a water heater meter with which the device undertaking the logic of FIG. 4 communicates that pertains to and/or indicates water level, water amount, water temperature, etc. of water in a water heating device-water heater as described herein. The logic may next proceed to block 402 where the logic may present data/information at a display of the device undertaking the logic of FIG. 4 and/or another device (e.g., other than the device undertaking the logic of FIG. 4 and the water heating device itself). The information may pertain to and or indicate a current amount of water in the water heating device, a current level of water in the water heating device, a current temperature of water in the water heating device, etc. Accordingly, this information may be viewed by a user when looking at the display on which it is presented to thus determine, e.g., an amount and temperature of water in the water heating device.

Moving on in the detailed description, FIG. 5 will now be described. It also shows example logic that may be executed by a device such as the system 100 in accordance with present principles (referred to below when describing FIG. 5 as the “present device”), such as a smart phone receiving data from a device undertaking the logic of FIG. 3 described above. Beginning at block 500, the logic may receive and/or process input from a water heater meter with which the device undertaking the logic of FIG. 5 communicates that pertains to and/or indicates water level, water amount, water temperature, etc. of water in a water heating device-water heater as described herein. The logic may then proceed to block 502 where the logic may determine an activity to be engaged in by a user of the present device, and/or may determine whether at least one peak water usage time is ongoing or upcoming (e.g., will begin within a threshold time of when the logic makes such a determination at block 502).

To determine an activity to be engaged in by the user, the logic may, for example, determine a location within a building at which present device is disposed (and hence the user is assumed to be disposal) based on coordinates from a GPS transceiver on the present device. Once the location is determined, the logic may access data associated with that location (e.g., stored at the present device or elsewhere), such as metadata indicating that the location is associated with an item such as a shower, a sink, a washing machine, etc., and also access corresponding data pertaining to an activity associated with the location and/or item. Such data may be stored, e.g., in a data table accessible to the present device.

Still further, location may be identified using received signal strength indication (RSSI) principles based on communication of the present device with another device to identify a location of the present device and accordingly an activity to be engaged in. Moreover, in some embodiments, a history of activities engaged in by the user at past times may be accessed and used to determine an activity to be engaged in based on the activity to be engaged in being correlated to a current time of day matching a time of day in the history at which the activity was previously engaged in.

The activity may also be determined still other ways. E.g., particular users may be associated only with particular activities, and hence by identifying the user (e.g., based on being associated with the present device) the activity may also be identified. An example data table will be described below in reference to FIG. 6 that may be accessed to make such a determination.

As another example, a user's interaction with another device (e.g., inputting a command to the other device) at a particular location may be identified (and communicated to the present device if the interacted-with device is not the device undertaking the present logic), which may then be used to identify an item at the location and hence an activity to be engaged in at the location using the item as described herein. Thus, it is to also be understood that to some embodiments, interaction with a device disposed at a particular location may itself be used as an indication from a user of an activity in which the user is to engage. For instance, if the user interacts with a touch-enabled display of a smart shower, the logic may determine that a user is about to take a shower responsive to this interaction with the touch-enabled display.

Regarding at least one peak water usage time that is upcoming or ongoing, this may be identified at block 502 by accessing a data table storing data that correlates particular times and/or time ranges to other data, such as the time/range being associated with an indicator that the time/range is one correlated to peak water usage, and/or such as the time/range being associated with particular average amounts of water from the water heating device that is consumed during that particular time/range in the past. These average water amounts may then be, e.g., compared to a threshold amount above which the logic may determine that the time-range is a peak water usage time and below which the logic may determine that the time/range is not a peak water usage time. An example of such a data table will be described below in reference to FIG. 7.

Still in reference to FIG. 5, from block 502 the logic may proceed to block 504 where, if available, a profile and/or profile information associated with an identified user may be accessed to determine or estimate whether there is currently enough water in the water heating device (and even whether the water is at least at or above a threshold temperature) for the user to engage in the activity determined at block 502 using water from the water heating device without running out of water from the water heating device before conclusion of the activity. In some embodiments, the logic may also determine or estimate whether there is currently enough water and whether the water, even if enough, is at least at a particular threshold temperature below which the logic may determine/estimate that there is not enough water for the activity and above which the logic may determine/estimate that there is enough water for the activity. In any case, the logic may determine/estimate whether there is enough water for the activity by identifying an amount of water from the profile that is to be used for the activity (e.g., that was determined and stored based on past instances of the user's engagement in the activity), and then comparing the amount of water from the profile to the current amount of water in the water heating device (e.g., as sensed by the water heating device's sensor(s)) to determine whether the current amount of water is at least the same as, if not more than, the amount of water indicated in the profile.

Furthermore, note that if a peak water usage time was identified at block 502, at block 504 the logic may estimate whether the water heating device contains enough hot wafer to meet an amount of water estimated to be consumed during the peak water usage time based on a history of past usage amounts during similar or the same times. The past amount(s) may be compared to the current amount of water in the water heating device (e.g., as sensed by the water heating device's sensor(s)) to determine whether the current amount of water is at least the same as, if not above, an amount of water previously consumed during a similar peak water usage time.

Before moving on in the description of FIG. 5, note that the profile information and/or peak water usage time information describe above may be identified from data tables, such as those to be described below in reference to FIGS. 6 and 7, respectively.

From block 504, the logic may next proceed to decision diamond 506. At diamond 506 the logic may determine whether to output data and/or notifications pertaining to the water heating device, such as based on whether an amount of water and/or temperature of water in the water heating device is at or below a threshold, whether there is currently enough water in the water heating device to fulfill the peak water usage time needs and/or water needed for the activity to be engaged in, etc. The decision at diamond 506 may be based on, for example, user-configured settings for whether to provide data/notifications and under what conditions. The decision at diamond 506 may also be based on other factors, such as if the present device has been programmed to only provide data/notifications if there is not enough water in the water heating device to meet peak water usage needs and/or to supply enough hot water to engage in the predefined activity until its conclusion.

Regardless, note that a negative determination at diamond 506 may cause the logic to move to block 508, where the logic may revert back to block 500 and proceed therefrom. However, an affirmative determination at diamond 506 may instead cause the logic to proceed to block 510, at which the logic may determine one or more devices at which to present the data and/or notifications described herein. Devices at which to present the data/notifications may be determined hased on user-configured settings of which devices the user wishes to have output the data/notifications. For instance, the user may provide a command to the present device to always present such data/notifications at the user's smart phone, a wearable device, a display centrally-located and/or located within a common area of a building that is used to control home automation and/or smart devices in the building, etc.

Such devices may also be determined based on the devices being associated (e.g. in a data table accessible to the present device) with the particular activity or activities determined to be engaged in, and/or item to be used during the peak water usage time. For instance, if a shower is determined to be the activity to be engaged in, the data/notifications may be determined to be presented on a display of a shower area. If washing dishes is determined to be the activity to be engaged in, the data/notifications may be determined to be presented on a display in a room in which a sink at which dishes are washed is disposed. If a washing machine and shower are determined to be items to be used during a peak water usage time, the data/notifications may be determined to be (e.g., constantly) presented on displays respectively at the shower and washing machine during the peak water usage time.

From block 510 the logic may move to block 512. At block 512 the logic may output the data/notifications at the devices determined at block 510. Note that in addition to presenting the data/notifications on displays as described above, the data/notifications may be presented to a user still other ways. For example, the data and/or notifications may be provided audibly, such as using an automated voice to convey water amount and water temperature, and/or such as using particular sounds, alarms, chimes, etc. which are respectively associated With different statuses of the water heating device (e.g., a relatively high-pitched chime may be presented to convey that there is enough water in the water heating device to engage in a particular activity, while a relatively low-pitched chime may be presented to convey that there is not enough water). In other embodiments, a sound may only be presented if there is enough water, or if there is not enough water.

Haptic indications may also be used to provide the data and/or notifications. For example, a first vibration pattern (using a vibration element at the device being used to provide the data/notification(s)) may be associated with and hence convey that there is enough water in the water heating device to engage in a particular activity, while a second vibration pattern may be associated with and hence convey that there is not enough water. In other embodiments, a vibration may only be presented if there is enough water, or if there is not enough water.

Still further, one or more light emitting diodes (LEDs) on such a device may be used to provide the data/notifications. For example, an LED may be illuminated with a green color if the present device determines that there is enough water for a particular activity and/or the demands of an upcoming peak water usage time, while the LED may be illuminated with a red color if the present device determines that there is not enough water. Furthermore, intensity and/or luminosity of the LED(s), such as luminosities on a scale of one to ten, may also be controlled to convey the data/notifications. For instance, a relatively less luminous green may convey that there is just enough water to engage in an activity while a relatively more luminous green may convey that there is more than enough water (and hence, e.g., the activity may be engaged in for longer than usual, if desired). As another example, a relatively less luminous red may convey that there is barely not enough water to engage in an activity and that hot water may be unavailable toward the end of the activity, while a relatively more luminous red may convey that there is not enough water by more than a threshold amount and that hot water will run out relatively soon and/or early in the activity.

Still in reference to FIG. 5, from block 512 the logic may next proceed to block 514. At block 514 the logic may, as the activity is being engaged in and as the peak water usage time transpires, identify a current consumption rate of water from the water heating device (e.g., based on input from a flow meter (and or water level sensor) or drainage meter at the water heating device and/or the item being used for the activity/during the peak water usage time). Thus, as the amount and/or temperature of water in the water heating device changes through time during and owing to the activity and/or peak usage, this may be identified at block 514 and, also at block 514, the data and/or notifications that are presented may be modified accordingly (and/or new data notifications may be provided) reflecting whether (for example), based on the current rate of consumption, there will still be enough water in the water heating device for the user to complete the activity and/or last through the peak water usage time with enough water from the water heating device being available to meet those demands.

From block 514 the logic may next proceed to block 516, where the logic may increase an amount and/or temperature of water in the water heating device, such as responsive to a determination at block 514 that, based on the current rate of consumption, there will not be enough hot water to supply through completion of the activity and/or peak usage time based on a current amount and/or temperature of water in the tank. In this way, the present device may at least attempt to provide enough hot water for the activity/peak usage time despite the current rate of consumption.

From block 516, the logic of FIG. 5 may then move to block 518 where the logic may create and/or update a profile or other data with information pertaining to water usage by a user for the activity being engaged in and/or just concluded (e.g., update an average of water consumed for die particular activity). In addition to or in lieu of the foregoing, but also at block 518, the logic may create and/or update data regarding water usage amounts during a peak water usage time that has just transpired (e.g., update an average of water consumed during die peak water usage time). From block 518 the logic may then revert back to block 500 and proceed therefrom.

Now in reference to FIG. 6, an example data table 600 that may be accessed by a device undertaking present principles is shown. The table 600 includes a first column 602 listing various users and/or user identifications. The table 600 also includes a second column 602 listing respective activities associated with each user listed in column 602, a third column 604 listing respective average amounts of water associated with each activity listed in column 604, a fourth column 608 listing respective average durations associated with each activity listed in column 604, and a fifth column 610 listing respective average temperatures of water used to engaged in each activity listed in column 604 (e.g., as determined based on input from a flow meter, drainage meter, and/or temperature sensor located at the item used to engage in the activity to measure temperature of water being used).

Providing an example of how the data table 600 may be used, suppose a smart phone identifies Arnie as a user, such as based on biometric input to the smart phone that is used to identify Arnie or based on the smart phone being associated with Arnie. The smart phone may then access the data table 600 and parse entries in column 602 until an entry for Arnie is identified (which, in this case, is the first entry). The smart phone may then move horizontally over to column 604 to determine that an activity with which Amie is associated is a shower, then move horizontally over to column 606 to determine that the average amount of water Arnie consumes to take a shower is twenty five gallons, then move horizontally over to column 608 to determine that Arnie takes a ten minute shower on average, and then move over to column 610 to determine that Arnie takes a shower using a water temperature of one hundred five degrees Fahrenheit on average. The foregoing data may then be used in accordance with present principles.

Moving on, reference is now made to FIG. 7, which shows an example data table 700 that may be accessed by a device undertaking present principles. The table 700 includes a first column 702 listing various time ranges, a second column 704 listing average amounts of water respectively consumed during the respective time ranges listed in column 702, and a third column 706 listing whether the respective time ranges are peak times during which water from a water heating device is used that may be respectively based on the average amounts listed in column 704.

Providing an example of how the data table 700 may be used, suppose a smart phone identifies a current time of day as being 6:30 p.m. The smart phone may access the table 700 and parse entries in column 702 until an entry is identified for a time range listed in the column 702 that includes the current time of day, which in this case would be the third entry down for the range from 5:00 p.m. to 11:59 p.m. The smart phone may then move horizontally over to column 704 to identify an average amount of water consumed during that time range, and either identify that 6:30 p.m. is a peak water usage time based on the data itself indicated in column 704 for the entry (such as based on whether the amount in the entry is above a threshold amount that makes it a peak water usage time), or then move horizontally over to column 706 to identify that 6:30 p.m. is a peak water usage time based on an affirmative indication of such at column 706.

However, note that in other embodiments, once a time range is identified from column 702 in which the current time of day falls, the smart phone may move horizontally over from column 702 directly to column 706 to determine whether the current time of day is during a peak water usage time frame based on data indicated in column 706 for the entry.

Continuing the detailed description in reference to FIG. 8, it shows a user interface (UI) 800 comprising example notifications that may be presented on a display in accordance with present principles. The UI 800 includes a first example notification 802 that indicates a number of gallons of hot water that is currently housed in a water heating device/water heater. In the present example, the notification 802 indicates, with underlining, that fifty gallons of hot water are available for use.

The UI 800 also includes a second example notification 804 that indicates a current temperature of the hot water in the water heating device, which in the present example is indicated, with underlining, as being one hundred seventeen degrees Fahrenheit. The UI 800 further includes a third example notification 806 that indicates that, at the current consumption rate of water from the water heating device, hot water from the water heating device will run out in twenty minutes at a specific time (9:17 p.m.). The UI 800, and/or any of the notifications presented thereon, may be presented, for example, regardless of any activity determined to be engaged in and/or without a determination regarding such an activity being made. Thus, for example, the notifications on the UI 800 may be presented on a display of the water heating device itself, on a home screen of a home automation system, and/or on a user's smart phone at any time so that a user may, regardless of activity and/or peak water usage time, see how much water is currently being housed in the water heating device and at what temperature.

FIG. 9 shows another example UI 900 presentable on a display in accordance with present principles. The UI 900 may be presented, for example, once an activity to be engaged in has been identified in accordance with present principles. In the present example, indication 902 indicates that the activity determined to be engaged in is a shower. Notification 904 indicates an estimated amount of time remaining before a water heating device is no longer able provide hot water based on a current consumption rate and/or an activity to be engaged in. In this case, notification 904 indicates that eight minutes of hot water remain in the water heating device (e.g., with this duration being determined/estimated based on an average flow rate of hot water from the water heating device for the shower activity). As may also be appreciated from FIG. 9, the notification 904 may also provide a reason that only eight minutes of hot water remain, which in this case is that hot water from the water heating device is already being used by a dish washer. Still further, note that the notification 904 may also indicate, in addition to an amount of time, an estimated time at which the water heating device will no longer be able provide hot water based on the current consumption rate and/or an activity to be engaged in, which in this case is at 8:28 p.m.

The UI 900 also includes a second notification 906 indicating an estimated amount of time to pass before die water heating device is able to provide enough (e.g., quantifiable, ample, measurable, gaugeable, etc.) hot water for the shower activity, which in this case is fifteen minutes. The notification 906 may also indicate an estimated time at which the water heater will be able to provide enough hot water for the shower activity, which in this case is 8:35 p.m. Furthermore, note based on FIG. 9 that, in some embodiments, the notification 906 may specifically indicate when the water heater will be able to provide enough hot water based on the average length that the user has engaged in the shower activity in the past, as also indicated on the UI 900 (in this case, as being a fifteen minute duration).

Moving on, reference is now made to FIG. 10, which shows another example UI 1000 presentable on a display in accordance with present principles. The UI 1000 includes a notification 1002 indicating that hot water from a water heating device is currently unavailable for use. The notification 1002 may also indicate an amount of time to wait before hot water is available for use (in this example, thirty minutes), and/or may indicate a future time at which water from the water heating device will be available for use (in this example, 12:30 p.m.).

Continuing the detailed description in reference to FIG. 11, it shows an example UI 1100 that may be presented on a display for configuring settings of a device for undertaking present principles. The UI 1100 includes a first setting 1102 at which a user may select one or more options 1104-1112 corresponding to times and/or circumstances under which the device is to present notifications in accordance with present principles, it being understood that each respective one of the options 1104-1112 may be selected using the respective cheek boxes 1114 shown adjacent to each option 1104-1112.

As may be appreciated from FIG. 11, option 1104 may be selected to enable presentation of notifications regarding water housed in a water heating device to always be presented, option 1106 may be selected to enable presentation of notifications when only a threshold amount of time for consumption remains (e.g., based on a current consumption rate), option 1108 may be selected to enable presentation of notifications when only a threshold amount of water for consumption remains (e.g., based on the current consumption rate), an option 1110 may be selected to enable presentation of notifications only when no water is available in the water heating device for consumption, and an option 1112 may be selected to enable presentation of notifications only when the temperature of water in the water heating device drops below a threshold temperature.

As may be appreciated from FIG. 11, option 1106 includes a number entry box 1116 at which a user may enter a number to establish the threshold amount of time for that option, while option 1108 includes a number entry box 1318 at which a user may enter a number to establish the threshold amount of water for that option and option 1112 includes a number entry box 1120 at which a user may enter a number to establish the threshold temperature for that option.

Still describing the UI 1100, in some embodiments it may also include a second setting 1122 that may be enabled based on selection of radio button 1124 to configure a device undertaking present principles to access and use profile information and/or history information (such as for particular users, activities, etc.) when undertaking present principles. The setting 1122 also includes a selector 1126 that is selectable to cause the device to present another user interface at which a user may establish and/or enter data for use regarding such users, activities, etc.

The UI 1100 may also include a third setting 1128 that may be enabled based on selection of radio button 1130 to configure the device to access and use peak water usage time frame information when undertaking present principles. The selling 1128 also includes a selector 1132 that is selectable to cause the device to present another user interface at which a user may establish times and/or time frames that are to be considered peak water usage times and/or non-peak water usage times.

Moving on from FIG. 11, it is to be understood in accordance with present principles that in some embodiments, when it is determined that a user has begun an activity in accordance with present principles (such as taking a shower), a device undertaking present principles (e.g., executing the logic of FIG. 5) may start a timer to back how long the user engaged in the activity from beginning to conclusion. This information may then be used to create or update a profile associated with the user that includes information pertaining to an average time that a user engages in the activity, an average amount of hot water consumed, and an average temperature at which the user used the hot water. This profile and/or dam may be stored, e.g., in storage at the water healer itself, on the user's personal device, at a server or cloud storage, or any other place accessible to other devices that may undertake present principles. Furthermore, note that a device may be able to estimate how much hoi water may be needed for a particular activity based on a user's water temperature preference by, e.g., determining how much hot water is mixed or released per second with cold water from another source (e.g., a cold water line) during an activity, and/or that is mixed or released per second with cold water from another source and into a fluid line that goes to the item where the mixed water is being consumed.

It may now be appreciated that present principles provide devices, systems, and methods for monitoring hot water use at a water heater as water is being emptied from the tank. A device undertaking present principles may also have access to historical usage information based on people and/or devices to provide real-time information to a user for whether the user can actually use hot water or how long to wait until hot water may be replenished. For example, if a first user uses one third of all available hot water in a water heater for a shower and a dishwasher also uses hot water from the water heater, and then a second user wishes to fill a bath tub with hot water, prior to taking the bath the second person may be informed that they need to wait eight minutes in order to have sufficient hot water to fill the bath tub. Present principles also recognize that, for example, a water heater may be configured to automatically raise the temperature of water therein to allow for more reserve of hot water during peak usage times, and/or to accelerate or move forward a time at which a determined amount hot water will be available for a user to engage in a particular activity as described herein.

Furthermore, it is to be understood that output in accordance with present principles that is related to a water heater may be presented at the water heater itself (such as at a display or speaker thereon) and/or at another device, such as at a user's smart phone, at a display (e.g., LCD or LED) associated with a shower, and/or at a display mounted in a bathroom of a personal residence. Even further, microphones of various devices in an Internet of things environment may be actuated in accordance with present principles to receive audible input from a user pertaining to a status, amount, temperature, etc. of water in the water heater and an output to the user may be provided in response.

For instance, in an Internet of things environment, a microphone may be located at or near a shower head and a user may provide input to that microphone asking if there is enough hot water for the user to take a shower. A device undertaking present principles may process that audible input and then generate output to be presented at a speaker at or near the shower in response, such as output indicating to the user that there is enough hot water available or indicating that the user should wait a particular amount of time before taking a shower.

Before concluding, it is to be understood that although a software application for undertaking present principles may be vended with a device such as the system 100, present principles apply in instances where such an application is downloaded from a server to a device over a network such as the Internet. Furthermore, present principles apply in instances where such an application is included on a computer readable storage medium that is being vended and/or provided, where the computer readable storage medium is not a transitory signal and/or a signal per se.

While the particular WATER HEATER MONITORING is herein shown and described in detail, it is to be understood that the subject matter which is encompassed by the present application is limited only by the claims.

Claims

1. A first device, comprising:

a processor; and

storage accessible to the processor and bearing instructions executable by the processor to:

receive input from a water healer meter that monitors a water heater; and

based on the input, provide an output comprising information pertaining to a time estimate related to the provisioning of heated water.

2. The first device of claim 1, wherein the time estimate is one or more of: an estimated amount of time remaining before the water heater is no longer able provide hot water based at least on a consumption rate, an estimated time at which the water heater will no longer be able provide hot water based on at least a consumption rate, an estimated amount of time to pass before the water heater is able to provide hot water, and an estimated time at which the water heater will be able to provide hot water.

3. The first device of claim 1, wherein the water healer meter monitors an amount of water associated with the water heater.

4. The first device of claim 1, wherein the water heater meter monitors a temperature of water associated with the water heater.

5. The first device of claim 1, wherein the instructions are executable by the processor to:

provide the output at the first device.

6. The first device of claim 5, comprising a display accessible to the processor, and wherein the output is provided on the display.

7. The first device of claim 1, wherein the instructions are executable by the processor to:

provide the output to a second device different from the first device.

8. The first device of claim 7, wherein the second device is a device at which an activity is to be engaged in using water from the water heater.

9. The first device of claim 1, wherein the output comprises information pertaining to one or more of: an amount of water in the water heater, and a temperature of water in the water heater.

10. The first device of claim 1, wherein the instructions are executable by the processor to:

raise the temperature of water in the water heater to accelerate a time at which a determined amount hot water from the water heater will be available.

11. The first device of claim 1, wherein the instructions are executable by the processor to:

store information pertaining to at least one use, by a particular user for a particular activity, of water from the water heater.

12. The first device of claim 11, wherein the instructions are executable by the processor to:

estimate, based on the stored information and based on input from the water heater meter, whether the water heater currently contains enough water for the particular user to engage in the particular activity using water from the water heater, and

provide the output based on the estimation.

13. The first device of claim 11, wherein the information comprises data pertaining to one or more of:

an identity of the particular user, the activity, an amount water from the water heater that was consumed to engage at least once in the predefined activity, a duration that water from the water heater was consumed to engage at least once in the predefined activity.

14. A method, comprising:

receiving input from a water heater meter that monitors a water heater; and

based on the input, presenting an output pertaining to a time at which water from the water heater will be ready for use to engage in a particular activity.

15. The method of claim 14, wherein the output comprises information pertaining to an amount of water in the water heater.

16. The method of claim 14, wherein the output comprises information pertaining to a temperature of water in the water heater.

17. The method of claim 14, wherein the time is a current time, and wherein the output indicates that water from the water heater is ready for use to engage in the particular activity.

18. The method of claim 14, wherein the output comprises information pertaining to a current availability of hot water from the water heater.

19. The method of claim 14, comprising:

presenting the output at least in part by one or more of: actuating a light emitting diode (LED), providing an audio indication, and providing a haptic indication.

20. A water heating device, comprising:

a water heater;

a water tank that holds water heated by the water heater;

a processor;

a network transceiver accessible to the processor;

a sensor accessible to the processor and that monitors water in the water tank; and

storage bearing instructions executable by the processor to:

receive input from the sensor; and

based on the input, provide data to another device using the network transceiver, the data pertaining to whether the water heating device holds enough hot water to supply hot water throughout performance of a particular activity.

21. The water heating device of claim 20, wherein the instructions are executable by the processor to:

during supply of water tor the particular activity, increase a temperature of water in the water heating device responsive to a determination that, based on a current rate of consumption, there will not be enough hot water to supply through completion of the particular activity.

22. A method, comprising:

receiving input from a water heater meter that monitors a water heater; and

based on the input, providing an output comprising information pertaining to a time estimate related to the provisioning of heated water.