Energy Efficient Sensor

Abstract

A sensor is discloses that uses very little power by entering a sleep state, waking up, finding a sensor or other device to report to, then going back to sleep for the next sleep cycle. The sensor may need to add itself onto its network. To do so, keys are exchanged with the network provisioner, the sensor informs the network of its capabilities, and/or characteristics, etc, and the network determines which other sensors and other places in the network the sensor may talk with.

Description

RELATED APPLICATION

The present application hereby incorporates by reference the entirety of, and claims priority to, U.S. Provisional Patent Application Ser. No. 63/070,460 filed 26 Aug. 2020.

COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF INVENTION

The present disclosure relates to sensors; more specifically, sensors that manage energy efficiently.

BACKGROUND

Sensors are widely used and widely useful. However, sensor energy consumption can be significant, especially in wireless sensor networks, which both have a limited power supply and large energy uses. In addition, many sensors are in locations that make it hazardous, expensive, or impossible to replace exhausted batteries.

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description section. This summary does not identify required or essential features of the claimed subject matter. The innovation is defined with claims, and to the extent this Summary conflicts with the claims, the claims should prevail.

In general, some technologies described herein describe an energy efficient sensor.

In embodiments, there is a first sensor, the first sensor comprising a solar panel, a battery, and sensor data, the first sensor operationally able to encode an active state, a sleep state, and a time period; wherein the first sensor is operationally able to use solar power or battery power to: enter the sleep state for the time period, enter the active state at end of the time period, and while in the active state, send a sensor data report to a second device, the sensor data report comprising at least a portion of the sensor data; and after the sensor data has been reported, enter the sleep state.

In embodiments, the first sensor is operationally able to enter the sleep state after the second device has indicated it has received the sensor data report.

In embodiments, when, after a report time period, the second device has not indicated it has received the sensor data report, the first sensor is operationally able to send the sensor data report to a third device.

In embodiments, the battery is operationally able to recharge using ambient light.

In embodiments, a second sensor is operationally able to send and receive wireless signals from the first sensor at a distance up to 150 feet.

In embodiments, a third sensor is included, wherein the first sensor, the second sensor, and the third sensor are operationally able to be connected using a self-healing mesh.

In embodiments, the first sensor is one half inch wide or smaller.

In embodiments, the first sensor comprises a sensor for air temperature, radiant temperature, humidity, volatile organic compounds, CO2, occupancy, floor temperature, rainfall, or air quality.

In embodiments, the first sensor further comprises a power wire, and wherein the first sensor is operationally able to be wired into an electrical system using the power wire.

In embodiments, the first sensor further comprises a sensor for occupancy, and wherein the sensor works with a controller to track occupant locations using mesh trilateration.

In embodiments, the first sensor notices a wireless signal from a personal electronic device, the wireless signal comprising strength and directionality.

In embodiments, the first sensor comprises a sensor for air temperature, humidity, CO2, VOC, and light level, occupant mapping, and occupancy detection.

In embodiments, the first sensor further comprises a sensor for occupant mapping, occupancy detection, and occupancy velocity.

In embodiments, the first sensor further comprises a sensor face, and wherein the sensor face displays historical values of the sensor data.

In embodiments, the first sensor further comprises a sensor for occupant mapping, occupancy detection, and occupancy velocity.

In embodiments, the first sensor further comprises a sensor face, and wherein the sensor face displays historical values of the sensor data.

In embodiments, a sensor minimal power usage method is disclosed, comprising: a sensor entering a sleep state; the sensor waiting for a designated time; the sensor entering an active state; the sensor reporting data; and the sensor entering the sleep state.

In embodiments, a sensor waits for a second designated time for a data reporting signal sending data to a second device.

In embodiments, a sensor uses ambient light to power a battery.

In embodiments, a sensor uses the battery to enter the sleep state, wait for the designated time, and enter the active state.

In embodiments, a sensor determines whether power mode type is standard, abundant, or unlimited.

In embodiments, a sensor determines at least one action based on power mode type.

In embodiments, a sensor energy saving system is disclosed, comprising: a solar panel, a battery, a processor with memory, and sensor data, the processor and memory in communication with a controller, the sensor operationally able to send the sensor data to the controller; and wherein the sensor is operationally able to send data to a second device after not receiving a signal from a first device.

These, and other, aspects of the invention will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. The following description, while indicating various embodiments of the embodiments and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions or rearrangements may be made within the scope of the embodiments, and the embodiments includes all such substitutions, modifications, additions or rearrangements.

BRIEF DESCRIPTION OF THE FIGS.

Non-limiting and non-exhaustive embodiments of the present embodiments are described with reference to the following FIGURES, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

FIG. 1 is a functional block diagram showing an exemplary embodiment of some features of a controller in conjunction with which some described embodiments can be implemented.

FIG. 2 is a functional block diagram showing an exemplary embodiment of some features of a memory in conjunction with which some described embodiments can be implemented.

FIG. 3 is a flowchart that discloses aspects of the sensor that may be used with embodiments disclosed herein.

FIG. 4 is a continuation of the flowchart in FIG. 3 that discloses aspects of the sensor that can be used in some embodiments disclosed herein.

FIG. 5, is a block diagram embodiment of a sensor that may be used in some embodiments disclosed herein.

FIG. 6 is a diagram that discloses some ways to charge a sensor battery that may be used with embodiments disclosed herein.

FIG. 7 discloses an embodiment of the sensor with which some described embodiments can be implemented.

FIG. 8 discloses a sensor network that uses a self-healing mesh with which some described embodiments can be implemented.

FIG. 9 discloses a diagram that describes some sensor-environment interactions in conjunction with which some described embodiments may be implemented.

FIG. 10 discloses a flowchart for waking an energy efficient sensor in conjunction with which some described embodiments can be implemented.

FIG. 11 discloses a flowchart for determining power mode for an energy efficient sensor in conjunction with which some described embodiments can be implemented.

FIG. 12 discloses a block diagram showing actions that may be taken when a neighbor sensor has low power in conjunction with which some described embodiments can be implemented.

FIG. 13 discloses an embodiment of the sensor with which some described embodiments can be implemented.

Corresponding reference characters indicate corresponding components throughout the several views of the drawings. Skilled artisans will appreciate that elements in the FIGURES are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments.

DETAILED DESCRIPTION

Disclosed below are representative embodiments of methods, computer-readable media, and systems having particular applicability to systems and methods for automatically creating wiring diagrams. Described embodiments implement one or more of the described technologies.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present embodiments. It will be apparent, however, to one having ordinary skill in the art that the specific detail need not be employed to practice the present embodiments. In other instances, well-known materials or methods have not been described in detail in order to avoid obscuring the present embodiments.“one embodiment”, “an embodiment”, “one example” or “an example” means that a particular feature, structure or characteristic described in connection with the embodiment or example is included in at least one embodiment of the present embodiments. Thus, appearances of the phrases “in one embodiment”, “in an embodiment”, “one example” or “an example” in various places throughout this specification are not necessarily all referring to the same embodiment or example. Modifications, additions, or omissions may be made to the systems, apparatuses, and methods described herein without departing from the scope of the disclosure. For example, the components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses disclosed herein may be performed by more, fewer, or other components and the methods described may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

For convenience, the present disclosure may be described using relative terms including, for example, left, right, top, bottom, front, back, upper, lower, up, and down, as well as others. It is to be understood that these terms are merely used for illustrative purposes and are not meant to be limiting in any manner.

In addition, it is appreciated that the figures provided herewith are for explanation purposes to persons ordinarily skilled in the art and that the drawings are not necessarily drawn to scale. To aid the Patent Office and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants wish to note that they do not intend any of the appended claims or claim elements to invoke 35 U.S.C. 112(f) unless the words “means for” or “step for” are explicitly used in the particular claim.

Embodiments in accordance with the present embodiments may be implemented as an apparatus, method, or computer program product. Accordingly, the present embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may be referred to as a “system.” Furthermore, the present embodiments may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

Any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. Computer program code for carrying out operations of the present embodiments may be written in any combination of one or more programming languages.

The flowchart and block diagrams in the flow diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, article, or apparatus.

Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). “Program” is used broadly herein, to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by programmers (who are also referred to as developers) and/or automatically generated. “Optimize” means to improve, not necessarily to perfect. For example, it may be possible to make further improvements in a program or an algorithm which has been optimized.

“Process” is sometimes used herein as a term of the computing science arts, and in that technical sense encompasses resource users, namely, coroutines, threads, tasks, interrupt handlers, application processes, kernel processes, procedures, and object methods, for example. “Process” is also used herein as a patent law term of art, e.g., in describing a process claim as opposed to a system claim or an article of manufacture (configured storage medium) claim. Similarly, “method” is used herein at times as a technical term in the computing science arts (a kind of “routine”) and also as a patent law term of art (a “process”). Those of skill will understand which meaning is intended in a particular instance, and will also understand that a given claimed process or method (in the patent law sense) may sometimes be implemented using one or more processes or methods (in the computing science sense). “Automatically” means by use of automation (e.g., general purpose computing hardware configured by software for specific operations and technical effects discussed herein), as opposed to without automation. In particular, steps performed “automatically” are not performed by hand on paper or in a person's mind, although they may be initiated by a human person or guided interactively by a human person. Automatic steps are performed with a machine in order to obtain one or more technical effects that would not be realized without the technical interactions thus provided.

Additionally, any examples or illustrations given herein are not to be regarded in any way as restrictions on, limits to, or express definitions of any term or terms with which they are utilized. Instead, these examples or illustrations are to be regarded as being described with respect to one particular embodiment and as being illustrative only. Those of ordinary skill in the art will appreciate that any term or terms with which these examples or illustrations are utilized will encompass other embodiments which may or may not be given therewith or elsewhere in the specification and all such embodiments are intended to be included within the scope of that term or terms. Language designating such nonlimiting examples and illustrations includes, but is not limited to: “for example,” “for instance,” “e.g.,” and “in one embodiment.”

The technical character of embodiments described herein will be apparent to one of ordinary skill in the art, and will also be apparent in several ways to a wide range of attentive readers. Some embodiments address technical activities that are rooted in computing technology, such as providing algorithms that improve sensor functionality by increasing sensor energy efficiency. Buildings can also be constructed more efficiently as benefits that are not apparent until the construction process can be implemented with little down-time, as sensors can easily be moved and without requiring network redefining or reworking. The sensors may be self-federating, and as such may require much less work than other sensor network systems. Other advantages based on the technical characteristics of the teachings will also be apparent to one of skill from the description provided.

I. Overview

Sensors may be used in buildings (and have models placed in digital twin models of the buildings) that are energy efficient. These energy efficient sensors may be solar powered, and/or may be able to recharge an on-board battery using ambient light. A sensor may have an active state and a sleep state. In the sleep state the sensor uses very little energy. They also may store sensor information. They may have a time period associated with them such that a sensor enters the sleep state it stays asleep for the time period, wakes up at the end of the time period, it enters the active state, records its sensor information, depending upon which kind of sensor it is (how hot it is, the humidity etc.), reports the sensor information, and then returns to sleep, repeating the cycle.

An embodiment describing the sensor wake cycle is shown in FIG. 4. Here, the sensor powers on, perhaps because its wake cycle has begun. Then, it checks if it has been added to the network. Provisioning, as described in the flowchart, is the process of adding a device (a node) onto the network. Keys are exchanged with the network provisioner, the sensor informs the network of its capabilities, and/or characteristics, etc, and the network determines which other sensors and other places in the network the sensor may talk with. The network provisioner may be a controller or a satellite controller.

The sensor may be wired to a controller, which may be a satellite controller, or the like, or may have a wireless connection. The wireless connection may be to a controller, a satellite controller, or the like. The sensor may report to any sort of device that accepts such a report, such as another sensor, a cell phone, an in-home controller, a satellite controller, a controller, etc. The sensor may be less than an inch tall. The sensor may be an inch tall or larger. The sensor may be one half inch wide or smaller. It may have a rechargeable battery. The battery may recharge automatically using ambient light. The battery may have a year of backup battery charge when the battery is fully charged. The battery may have more or less than a year of backup battery charge. The sensor may have more than a year of backup battery charge. The sensors can be wired up to power in a variety of ways. One embodiment of how the sensor manages its power needs is shown in FIG. 11, which is used for the discussion below.

The sensor can run off battery power, and/or solar power alone. In this instance, all power income is from the solar panel and/or battery. This means that the device must behave efficiently as to not run out of power. The sensor can tell roughly how much is power coming in and can operate in a series of “modes” which have a known power budget to prevent dying from lack of power. This is represented on the flowchart by the top level taking all the “n” (no) branches.

The sensor can be attached to ground and communication wires. This is represented in the flowchart by the decision node “1-wire” and taking the “y” branch. In such a case, power is not unlimited and instead is parasitically “syphoned” off of the communication line AND from solar, so the power budget is larger. The communication wire also means that the sensor has a direct connection to the access point through the communication line. In such instances, the operation mode is changed to support direct communication rather than just through a wireless connection.

The sensor can be attached to ground and to a power wire allowing wired usage. This is represented in the flowchart by the “wired power supply” decision node and taking the “y” branch. This configuration enables a power mode which is agnostic to the power expense of its actions and may do anything that must be done at any time.

In some instances, the sensor may be attached to a communication wire allowing for a wired connection between the sensor and some other portion of the building, such as another sensor, a controller, a satellite controller, etc.

Gateways are devices on the network which can communicate with another network. These devices are typically a controller box, but may also be satellite boxes, or a central computer separate from a controller. They are important because, in some embodiments, all information flows to them so that they may report new information to whatever device is at the highest level, which may be the master controller.

There may be a network of sensors connected wirelessly, they may be wired, or there may be a combination of wiring types. The sensor may report to a device that does not accept the information, because, for example, it is broken, has turned off, is off a network that the sensor is connected to as well, etc. In such a case, the sensor may automatically report to a second device. If the second also does not reply, or accept the information, the sensor may report to a third device, etc. For example, a sensor A may report to another sensor B, to which it is connected wirelessly. If B does not indicate that it is available to accept input, or indicates that it cannot accept input, then A will automatically attempt to send its information to sensor C. In another embodiment, the sensor reports to a first controller. If the controller does not accept the information, then the sensor reports to another device, which may be a different controller. One embodiment of passing messages is shown and described in FIG. 4.

Sensors may be connected using a self-healing mesh. Such sensors allows gathering deep occupant and building insights, which may cost less than a typical thermostat. Sensors may sense some combination of air temperature, radiant temperature, humidity, and air quality, volatile organic compounds, floor temperature, and rainfall,

Embodiments described herein may utilize a self-healing mesh network which reconfigures itself when a connection within the network is determined to be unreliable or when a specific node malfunctions. The network routes itself around the non-working portions. The specific method used may be a self-healing algorithm. Examples of suitable self-healing algorithms are: DASH: Degree Assisted Self Healing; Forgiving Tree; Forgiving Graph; Shortest-Path Bridging, etc.

II. System Embodiment

With reference to FIG. 1, a system is shown that may be used, in whole, or in part, in any of the embodiments disclosed herein. A sensor 100 is disclosed, which may be part of a building control system that determines the comfort level of a building, or a different sort of control system. This sensor may comprise a solar panel 105, a battery 110, and sensor data 115. The solar panel 105 may have an unwired light specification of 50 Lux at 8 hours, 40 Lux at 8 hours, 25 Lux at 8 hours, or a different specification. The battery autonomy may be 1 year with no light, 2 years with no light, or a different specification. The sensor data, in an illustrative embodiment, is data that the sensor senses and then stores. Not all sensed data may be stored., some may be sent immediately to a different device. The sensor data may be stored in memory 125. This memory may be flash memory, or a different sort of suitable memory. There may be a processor 120 on board which can make certain decisions, such as where to send data, may make calculations, such as determining energy data, and so on. The processor may be a microprocessor. The microprocessor may comprise high-efficiency signal processing, low power, low cost, or may have other features. The microprocessor may comprise the memory 125. A transmitter 130 may allow the sensor to send sensor data to another entity, such as a controller that controls the sensor 100, another sensor, or a different entity. The transmitter may be wired, wireless, some combination, etc. The transmitter may be a bluetooth mesh, a 2-wire multidrop, a 3-wire multidrop, or some combination of the above. The sensor may be able to monitor battery usage, battery power, etc., and report the battery information to a different entity.

With reference to FIG. 2, a block diagram 200 describes certain aspects of the sensor that may be used with embodiments disclosed herein. The sensor may be operationally able to encode a sleep state 205, an active state 210, a sleep time 215, and data 220. The active state 210, in some embodiments, indicates that the sensor is awake and able to communicate with the larger world, which may be another sensor, a controller, a personal electrical device such as a personal communication device, a cell phone, a satellite controller, etc. The sleep state 205, in some embodiments, indicates that the sensor is quiescent, using just a little energy, such as needed to run the time period timer. The sleep time 215 is the time that the sensor will stay asleep; or alternatively, the length of the report time period. This may be a fixed time, a time that is dependent on surrounding factors, such as the day of the week, special modes the system may be in, whether it is a holiday, the state the sensor is in, a time chosen by a user, etc. The sensor may sense and collect data about different states, such as air temperature, radiant distribution, atmospheric pressure, sound pressure, occupancy detection, occupancy mapping, occupancy velocity, indoor air quality, CO2 concentration, light intensity, etc. The temperature range may be from −40 to 85 C. The gradient temperature distribution may be from −60 to 400 C 1024 px. The humidity range may be from 0 to 100% RH. The CO2 range may be from 0 to 2000 PPM eq. The VOC range may be from 0 to 500 IAQ. The atmospheric pressure range may be from 300 to 1100 hPa. The light level range may be from 1− to 1,000 LUX. The Occupancy mapping may be at 1 m Resolution (nom). The occupancy detection may be up to 7 m (distance). The occupancy velocity range may be from 0.1 to 10 m/s.

The sensor data 220 may be used in a data report. Such a report may use all or some of the data. The data 220 used for the report may be based on the time the data was collected, the time the report will be sent, the amount of data, data that falls within or outside certain parameters, certain states only, all the states, etc.

III. Method Embodiment

With reference to FIG. 3, a flowchart 300 discloses methods that may be used with embodiments disclosed herein. At operation 305, a sleep state is entered. During the sleep state the sensor 100 uses very little energy. It, in some embodiments, the sensor uses the energy necessary to set and keep track of a timer that indicates the length of the sleep state. At operation 310, the sensor then waits for a time, which may be the length of the sleep state, or may be a clock time such as 3:00 am when the timer is to wake up. For further examples, this time may be a specified period of time, a period of time that is determined by other factors, such as time of day, etc. After the wait time is up, (or a specified clock time occurs, etc.), at operation 315, the sensor then enters an active state. During this active state, the sensor sends 310 a data report 320 comprising some portion of the sensor data 220, that the sensor has been storing. In some implementations, some previously stored data may be overwritten or erased. The rules for overwriting or erasing may be overwrite or erase based on time, based on amount of memory that is full, or a different approach as known by those with knowledge in the art. In some implementations, the sensor sends the data that the sensor is sensing at that time. In such cases, no memory may be necessary.

With reference to FIG. 4, at 400, a continuation of the flowchart 300 is described with certain aspects of the sensor that can be used in some embodiments. At 320, the sensor sends the data report. At 425 the sensor 100 waits for a signal that the data report has been successfully received by an entity that is accepting the data 220. This entity may be another sensor, a controller, a satellite controller, a personal information device like a cell phone or a personal computer, a specialized reporting device, and the like. If the sensor receives a signal that the data has been received, then the sensor returns to its sleep state 305.

In some embodiments, the sensor may wait for a signal indicating report reception for a second time 425, and then check if the sensor has received a signal of some type that the report has been received 430. If the data has been reported, then the sensor returns to its sleep state. In some embodiments, when a signal is received that data has been reported, the sensor immediately returns to its sleep state 305 without waiting for the second wait time 425. If the data has not been reported by the second wait time 425, then the sensor data report may be sent to a second device 435. The sensor may wait for the second time (or, in some embodiments a third time. The sensor then checks if the data has been successfully reported 445. If the sensor does not receive a signal that the report has been received, then the sensor data report may be sent to a third device 450. If sensor receives information that the data has been reported, then the sensor returns to its sleep state 305. Even though only three devices are shown on this flow chart, it should be understood by those of skill in the art, that the sensor can continue checking for some specified number of devices. If none of the specified devices are available, then the sensor returns to sleep 305, and tries again. In some implementations, if a sensor falls asleep because it was unable to connect with any device on a possible device list, then a different sleep time for the sleep state may be used. In some implementations, if a device does not receive the data, the sensor may receive a signal that includes a device the sensor should send the data to.

With reference to FIG. 5, a block diagram embodiment 500 of a sensor is shown that may be used with the embodiments disclosed herein. A sensor may comprise a battery 510, a solar panel 505 that may recharge the battery, a separate battery that is recharged by the solar panel, sensor data 515, and/or a wireless network connection 535 that allows it to send its sensor data to a device without being explicitly wired into a network. A sensor may also comprise a power wire 520 to tie the sensor into power; allowing the sensor to be wired into an electrical system, which allows it to run without danger of running out of battery. The sensor may also comprise a connection wire 525, which allows the sensor to connect through a wire to a network. A sensor may need not have every item shown here. For example, a sensor may not have a solar panel, a power wire, and a connection wire, may not have a connection wire, may not have a wireless network, etc. The sensor may also have a CPU 530 that may comprise a processor and memory. This CPU may allow the sensor to compute methods and algorithms described herein.

FIG. 6 discloses some ways 600 to charge a sensor battery. The sensor battery 605 may be able to recharge using ambient light 610, which is itself comprised of sunshine 620 and lights 615 in the space in which the sensor resides. Because sunshine can be used to recharge a sensor battery using, e.g., a solar panel, the sensor may be able to recharge when lights are not on in the sensor area, e.g., when an office is closed, when owners of a house are on vacation, etc.

IV. System Embodiment

FIG. 7 discloses an embodiment of the sensor 700. The sensor 700 may be ½ inch in width 710 or smaller. In some embodiments, the width 710 may be 0.445 inches. In some embodiments the diameter 730 is below 2.5 inches. In some embodiments, the diameter may be 2.12 inches. The sensor 700 and may have a light indication 705 to signify that the sensor is on. In some embodiments, the light indication may signify something else, such as that the sensor is transmitting information, the sensor is using battery power, etc. This light indication may be a semi-circle or may be a different shape. The sensor 700 may have a display 715 that indicates historical values for the sensor data. In some embodiments, the historical data is presented as a histogram. In other embodiments, the historical data may be presented as numbers, or in a different manner. The sensor display may also display the current state data values 720. Some sensors may have multiple sensing abilities, such that they can sense some combination of air temperature, humidity, CO2, VOC, light level, occupant mapping, occupancy detection, and occupancy velocity. In such a case, the current sensor values for the different sensing elements can be cycled through on the display 720. In some embodiments, a historical record of recent sensor values with an appropriate x and y axis can also be displayed in the sensor face 715. In some embodiments, different sensor historical values 725 are displayed behind the current sensor historical value on the sensor face. In some embodiments, users can set up what values are displayed on the sensor face, and when.

FIG. 13 discloses an embodiment of the sensor 1300. In some embodiments, there is no light indication. In some embodiments the diameter 1315 is below 2 inches. In some embodiments, the diameter is below 1.78 inches. In some embodiments the width 1310 is below 4.33 niche. In some embodiments, there are no historical values listed. In some embodiments, there is no current state data displayed. In some embodiments, there is no display 1305.

The sensor may be wired to a controller, which may be a satellite controller, or the like, may have a wireless connection, or may have both. The wireless connection may be to a controller, a satellite controller, another sensor, to a different device type, or the like. The sensor may report to any sort of device that accepts such a report, such as another sensor, a cell phone, an in-home controller, a satellite controller, a controller, etc. The sensor may be less than an inch tall. The sensor may be an inch tall or larger. It may have a rechargeable battery 510. The battery may recharge automatically using ambient light. The battery may have a year of backup battery charge when the battery is fully charged. The battery may have more or less than a year of backup battery charge. The sensor may have a solar panel that uses ambient light to charge the battery. The sensor may have a solar panel that is used for other purposes, such as for unexpected uses. An example of an unexpected use may be a user checking a sensor value outside of its regularly scheduled times.

FIG. 8 discloses a sensor network 800 that uses a self-healing mesh. The mesh may have a controller 805 that controls the sensors. This controller 805 may have a processor and memory allowing it to run computer programs stored in its memory. The controller 805 may also have a wired network connection, a wireless connection, or a combination of the two to communicate with the sensors and run the self-healing mesh. In some embodiments, the controller may be an all-purpose computer. The mesh may be partially connected or fully connected. The mesh may use a flooding technique or a routing technique. If the routing technique is used, in some embodiments, the message hops from sensor to sensor until it reaches its destination sensor. This mesh may comprise a connected network as shown at 810, which allows the network to route around a node (such as a sensor node 815), which has failed, by instead routing to sensor 820, and/or sensor 825. In some embodiments, sensors may be able to send and/or receive wireless signals from each other or from another device able to receive and/or send wireless signals up to a distance of 150 feet. In some embodiments, sensors may be able to send and/or receive wireless signals from each other or another device set up to receive and/or send wireless signals at a distance farther than 150 feet.

FIG. 9 discloses a diagram 900 that describes some sensor-environment interactions. A controller 905 may have a one- or two-way link 910 with a sensor 915. A sensor, such as sensor 915 may comprise a sensor that can determine occupancy. This sensor may work with a controller 905 to track occupant locations using strength and directionality of a personal electronic device wireless signal 920. A personal electronic device may be a cell phone, a personal computer, a tablet, or another sort of device that has wireless communication or has the ability to be connected to a network. The sensor may work with a controller 905 to track occupant locations. The occupants may be tracked using motion and/or heat using passive infrared. Occupants may be tracked using a counter sensor that uses object recognition to count people going in a single direction. Mesh trilateration may be used to determine number of occupants, and/or location of occupants in an area. Trilateration may be used, using infrared, ultrasound, or radio signals, some combination, etc. Position estimation may be performed using spherical trilateration, hyperbolic trilateration, signal strength trilateration, etc.

One or more sensors (e.g., in a network 800) may assume a variety of roles based on its power income and relationship to other devices in a network. Sensors may be used in buildings (and have models placed in digital twin models of the buildings) that are energy efficient. These energy efficient sensors may be solar powered, and/or may be able to recharge an on-board battery using ambient light. A sensor may have an active state and a sleep state. In the sleep state the sensor uses very little energy. They also may store sensor information. They may have a time period associated with them such that a sensor enters the sleep state it stays asleep for the time period, wakes up at the end of the time period, it enters the active state, records its sensor information, depending upon which kind of sensor it is (how hot it is, the humidity etc.), reports the sensor information, and then returns to sleep, repeating the cycle.

V. Method Embodiment

FIG. 10 discloses a flowchart 1000 that describes some methods for waking an energy efficient sensor. At operation 1005, the power is turned on, or it is noticed that the power is on, etc. At operation 1010, the sensor determines what its power mode is. The power mode determination is described with more specificity with reference to FIG. 11 and the surrounding text.

At operation 1015 the sensor is provisioned. Provisioning is the process of adding a device (a node) onto the network. Keys are exchanged with the network provisioner, the sensor informs the network of its capabilities, and/or characteristics, etc, and the network determines which other sensors and other places in the network the sensor may talk with. The network provisioner may be a controller or a satellite controller. A satellite controller is a controller with limited functionality. For example, a satellite controller may only allow a limited number of devices to attach to it, may have less memory and/or processing power, etc. At operation 1020, the sensor network connection is synced with the larger network. This may require several cycles of the device searching for the network for a given time until the device is synchronized with the network. At operation 1025, the next wake cycle is scheduled, and the sensor begins sleeping.

At decision node 1030, the sensor wakes, and determines if it woke to measure or for maintenance. If the device is to measure 1035, then the sensor may measure from some or all of its sensors, re-synchronize itself with its neighbors, and communicate its measurements back to a gateway, such as another sensor or a Chief If for a maintenance cycle 1040, the desired maintenance is performed. Then the sensor is synced with the network 1020, the next wake cycle is scheduled, and the sensor enters a sleep site 1025. During a network maintenance cycle a “Chief” will check if a user has decided to deprovision a device (perhaps to reuse it for another project). In some embodiments, the “Chief” will then tell the intended node to erase its memory of the network via a BT Mesh message and then will black-list it. The “Chief” is the device that is directing the sensor activity. This my be a controller, may be one controller in a connected controller system, may be a satellite controller, etc. In installations where there is at least one Controller, one will be designated as the “Chief” or “Master” of a sensor network. The “Chief” may be a special type of network gateway which is in charge of configuring, maintaining, and monitoring a network.

At decision node 1045, if the sensor has been deprovisioned 1045, then the sensor has been taken off the network. When a node is deprovisioned it may be blacklisted from communicating on the network and forced to forget all of its network credentials. To again be placed on the network, the node will need to go through power mode and role discovery 1010.

FIG. 11 discloses a flowchart 1100 that discloses some methods for determining a power mode and a role for an energy efficient sensor. The flowchart starts at operation 1105, Begin, for all sensors. At operation 1110, the power mode is set to Limited (indicating that only a limited amount of power is available), and the Role is set to Standard. At decision point 1115, the sensor or another entity, such as a “Chief,” determines if the sensor has a power wire that can be communicated across. This may be a 1-Wire power connection or a different sort of communication power wire. If yes, then at operation 1120, the Power Mode is set to Abundant (indicating that more power is available than when Limited is chosen), and the role is set to Gateway. A gateway is a device which communicates one or more protocols (such as BT Mesh and/or wife), and/or is connected to the internet. These gateway devices move info from the outside world (a Controller or similar) into the sensor network (which may be a BT Mesh). They also move data from the sensor network back to a controller.

At decision point 1125, the sensor or another entity, such as a “Chief,” determines if the sensor has a wired power supply. If so, at operation 1130, the Power Mode is set to Unlimited (e.g., more power than Abundant). At decision point 1135, it is determined (by the sensor or another entity, such as a “Chief,” if the sensor is provisioned. If so, then at decision point 1150, the algorithm stops. If it is not, then at decision point 1140, it is determined if the sensor is a single hop from a “Chief.” If not, then at operation 1150, the algorithm ends. If so, then at operation 1145, the role is set to “gateway.” In some networks, such as a mesh network, devices such as sensors may relay messages from other devices to help extend the effective distance of communication. If a device can directly communicate with its neighbor it is classified as a single-hop. If there must be one device to relay a message from one device to another, it is classified as a double-hop and so on. Effectively one hop is one transmit of a message. Each required relay increases the number of transmits by one.

FIG. 12 discloses a block diagram 1200 showing actions that may be taken when a neighbor sensor has low power 1205. Sensors may perform different roles depending on the state of other sensors in the network. For example, when a sensor is running out of power, neighboring sensors may take on some of the low power sensor's load. To determine if a sensor is running out of power, a sensor may monitor its own battery power. When it hits a threshold value, drops below a threshold value, etc., a sensor may send a low-power message to a nearby sensor 1210, for example, a sensor that is one hop away. This nearby sensor may then send the low power information to a “Chief.” The Chief may then lengthen the amount of time between reporting periods for the low power sensor, route messages sent between sensors around the low power sensor, etc. In some embodiments, the low power sensor lengthens the time between reporting (e.g., sleep) periods. In some embodiments, the low power neighbor may route all messages to a neighbor sensor that is 1-hop away 1220, or is within a shorter transmission radius, rather than sending some messages to a further sensor or Chief that would take more power. In some embodiments, the Chief or a neighbor sensor (e.g., 1 hop away, 2 hops away, etc.) observes the behavior of a sensor and is able to deduce from that behavior that the sensor is running low on power 1215. For example, the sensor may be difficult to connect to, may be sending most or all messages to an adjacent sensor (or other node), may be sending messages within a shorter distance than normal, may be lengthening sleep periods, etc. The Chief may then lengthen the amount of time between reporting periods for the low power sensor, route messages sent between sensors around the low power sensor, etc. A neighbor sensor (e.g., 1 hop away, 2 hops away, etc.) may observe the behavior of a sensor and be able to deduce from that behavior that the sensor is running low on power. For example, the neighbor sensor may be receiving many more messages from the low power sensor than is normal. In such a case, the neighbor sensor may pay special attention to the low power sensor and more readily relay messages from it further into the sensor network.

In view of the many possible embodiments to which the principles of the technology may be applied, it should be recognized that the illustrated embodiments are examples and should not be taken as a limitation on the scope of the invention. For instance, various components of systems and tools described herein may be combined in function and use. We, therefore, claim as our invention all subject matter that comes within the scope and spirit of these claims.

Claims

1. A device comprising:

A first sensor, the first sensor comprising a solar panel, a battery, a processor with memory, and sensor data, the first sensor operationally able to encode an active state, a sleep state, and a time period;

Wherein the first sensor is operationally able to use the processor with memory and solar power from the solar panel or battery power from the battery to:

enter the sleep state for the time period,

enter the active state at end of the time period, and

while in the active state, send a sensor data report to a second device, the sensor data report comprising at least a portion of the sensor data; and

after the sensor data has been reported, enter the sleep state.

2. The device of claim 1, wherein the first sensor is operationally able to enter the sleep state after the second device has indicated it has received the sensor data report.

3. The device of claim 2, wherein when, after a report time period, the second device has not indicated it has received the sensor data report, the first sensor is operationally able to send the sensor data report to a third device.

4. The device of claim 1, wherein the battery is operationally able to recharge using ambient light.

5. The device of claim 1, further comprising a second sensor, and wherein the second sensor is operationally able to send and receive wireless signals from the first sensor at a distance up to 150 feet.

6. The device of claim 5, further comprising a third sensor, wherein the first sensor, the second sensor, and the third sensor are operationally able to be connected using a self-healing mesh.

7. The device of claim 1, wherein the first sensor is one half inch wide or smaller.

8. The device of claim 1, wherein the first sensor comprises a sensor for air temperature, radiant temperature, humidity, volatile organic compounds, CO2, occupancy, floor temperature, rainfall, or air quality.

9. The device of claim 1, wherein the first sensor further comprises a power wire, and wherein the first sensor is operationally able to be wired into an electrical system using the power wire.

10. The device of claim 1, wherein the first sensor further comprises a sensor for occupancy, and wherein the sensor works with a controller to track occupant locations using mesh trilateration.

11. The device of claim 10, wherein the first sensor notices a wireless signal from a personal electronic device, the wireless signal comprising strength and directionality.

12. The device of claim 1, wherein the first sensor comprises a sensor for air temperature, humidity, CO2, VOC, and light level, occupant mapping, and occupancy detection.

13. The device of claim 12, wherein the first sensor further comprises a sensor for occupant mapping, occupancy detection, and occupancy velocity.

14. The device of claim 1, wherein the first sensor further comprises a sensor face, and wherein the sensor face displays historical values of the sensor data.

15. A sensor minimal power usage method comprising:

a sensor entering a sleep state;

the sensor waiting for a designated time;

the sensor entering an active state;

the sensor reporting data; and

the sensor entering the sleep state.

16. The method of claim 15, further comprising waiting for a second designated time for a data reporting signal; wherein when the data reporting signal is not received, sending data to a second device.

17. The method of claim 16, further comprising using ambient light to power a battery associated with the sensor.

18. The method of claim 17, further comprising a power mode and determining whether power mode is standard, abundant, or unlimited.

19. The method of claim 18, further comprising a role and determining whether the role is standard or gateway.

20. A sensor energy saving system, comprising: a solar panel, a battery, a processor with memory, and sensor data, the processor and memory in communication with a controller, the sensor operationally able to send the sensor data to the controller; and wherein the sensor is operationally able to send data to a second device after not receiving a signal from a first device.