Devices, systems, and methods for maintaining light intensity in a gateway based lighting system

The disclosure relates to devices, systems, and methods to set, adjust, and/or maintain lumen levels of luminaires in a lighting system, for example. The lights may be a plurality of Light Emitting Diode (LED)-based luminaires, which are part of a smart illumination system. In certain exemplary embodiments, sensor subsystems detect degradation of luminaire lumen levels and servers/gateways are used to adjust dimming controls to reestablish proper lumen levels and predict a half-life or end of life for the luminaires.

FIELD OF THE DISCLOSURE

The disclosure relates generally to commissioning and maintaining lighting systems. More specifically, the disclosure is directed to monitoring and maintaining the light intensity or lumen level of a luminaire or a group of luminaires that occupy the same or connected environment(s), for example and without limitation, spaces, rooms, and/or lit areas generally, using a lighting system incorporating, among other things, gateway-based dimming controls.

BACKGROUND OF THE DISCLOSURE

The lifetime of traditional light sources (incandescent, fluorescent, and high-intensity discharge lamps) is estimated through industry-standard lamp rating procedures. The number is typically determined by an operation that runs a large, statistically significant sample of a type of lamp until 50% have failed and that number of hours defines “rated life” for that lamp. Based on years of experience with traditional light sources, lighting experts can confidently use lamp life ratings, along with known lumen depreciation curves, to design the lighting for a space, and to determine equipment change schedules and economic payback. This aspect of predictive life or half-life of a light source is not true with Light Emitting Diodes (LED).

The primary reason why LED-based luminaires are immensely popular is because of their operational longevity and low power consumption. LEDs generally do not fail abruptly like traditional light sources; instead, their light output slowly diminishes over time. However, LED light sources can have such long lives that life testing and acquiring real application data on long-term reliability become problematic—new versions of products are available before current ones can be fully tested. On top of that, LED light output and useful life are highly dependent on electrical and thermal conditions that are determined by the luminaire and system design and environment.

Digital intelligent lighting control systems can switch and dim individual luminaries in a light scene or space (i.e., an “environment”), which provides a great amount of flexibility, for example, setting appropriate LED output under particular conditions including the level of LED lumen depreciation. For purposes of this disclosure, “environment” means generally and without limitation a space or area in which a luminaire or lighting system is installed. Such known lighting control systems have many user-friendly features for installation, programming, and operation. Lighting control systems can thus be integrated into a building management system as a subsystem of the central light controls.

A lighting control network includes one or more lighting devices; e.g., electrical ballasts (such as a luminaires), LED devices, and dimmers, among other things. In the case of dimmers, the dimmers must support specific interfaces for receiving control inputs and dimming the lights appropriately. Different lighting devices can support different control interfaces for dimming, e.g., to achieve a particular lumen level or light intensity as between different LED brands and/or powers.

The lumen level of a luminaire is the look and feel of the light produced by the luminaire. Current lighting control systems do not provide a system or method for allowing users to predict, after the fixture has been installed, when lumen degradation has occurred to the point where the light needs to be replaced. Current lighting control systems use, for example, environmental input sensors, which are directly connected to the luminaire to sense environmental conditions.

For example, current lighting control systems include a Digital Addressable Lighting Interface (DALI®) protocol-based system, which includes a controller, a driver, and a signal converter. The DALI® system is capable of regulating lumen level of a luminaire by adjusting a dimming level of the luminaire so long as the luminaire is the same make and type throughout the entire system, which has been pre-designed around such luminaires.

Thus, at least one drawback of the DALI® system and other current systems is that current systems may use a single or a fixed dimming control technology which may be set during lighting system commissioning and may not be adjusted during the life or state of degradation of a luminaire. Furthermore, these systems cannot control dynamic environments in which luminaires not present at the time of inception are introduced; that is, the lighting systems must be developed and tested with the technology and parameters available during initial commissioning of the lighting system. There is no system learning capacity to dynamically integrate new luminaires and different types of LEDs, for example, with different powers, into the system.

Thus, devices, systems, and methods for allowing a user who installs tens of thousands of luminaire systems to predict when and how much every luminaire has been degraded and/or adjust dimming level control over time provides enhanced convenience, control, and economics in lighting systems. The devices, systems, and methods may scale to very large numbers of luminaires at a global level. Such devices, systems, and methods may, for example, identify in real time the current state, such as ON/OFF, lumen level, and/or degradation state of at least one luminaire.

Such devices, systems, and methods may also be capable of maintaining the lumen levels of each luminaire regardless of dimming protocols, type of luminaire, or environmental characteristics associated with the luminaire.

Further, current techniques for luminaire dimming may be controlled by multiple standard protocols. The implementations are varied and the results cannot be correlated. The luminaires can control their light intensity or lumen level one at a time; e.g., every luminaire can have a sensor and a dimming control that can be set to a specific lumen level. Thus, when a group of luminaires occupy the same space, or same room, those luminaires will often be identical otherwise controlling the dimming level will not project a correct lumen level in the room. On the other hand, devices, systems, and methods which allow for any dimming protocol to be in the same space with a variety of luminaires/LEDs and yet generate a specific, overall lumen level for the space using the sensors and dimming control in real time provide further flexibility in lighting control systems.

For purposes of this disclosure, “protocol” means, for example and without limitation, one or more instructions, sequences, processes, algorithms, responses, or actions.

For purposes of this disclosure, “real time” means substantial concurrency. “Real time” is not used to imply any particular timeframe or limitation.

BRIEF DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

The disclosed exemplary embodiments are directed generally to devices, systems, and methods that set, adjust, and/or maintain appropriate lumen levels or light intensity of lights. The lights may be a plurality of LED-based luminaires, which are part of a smart illumination system. The system includes, among other things, one or more gateway devices that are connected to the LED-based luminaires over wired and/or wireless technologies and to cloud servers at least in part over wireless networks. The disclosed devices, systems, and methods may be used locally to a luminaire, as well as by utilization of Internet of Things (IoT) networks in which luminaires of a lighting system are identified and stored on, e.g., web- or cloud-based networks. The exemplary disclosed devices, systems, and methods may set, control/adjust, and/or maintain the overall lumen level or light intensity of a luminaire or an environment in which one or more luminaires is installed according to a user designed setting or other level or protocol.

The exemplary disclosed devices, systems, and methods of handling lumen level or light intensity variation over time take into consideration, among other things, all of the factors mentioned above including lumen degradation, environmental conditions, the number and type of luminaires/LEDs in an environment, the requisite or desired lumen level in an environment, and/or other factors as may be disclosed herein. The exemplary disclosed embodiments generally include a plurality of sensors such as at least one up looking color sensor that measures changes in lumen level or light intensity at a luminaire/LED relative to a baseline. The baseline is set dynamically by the systems and methods in order to adapt to changes in hardware or environment inputs. The systems and methods can also support individualized user setups. Individualized setups may include, for example and without limitation, multiple parameters such as lumen level, dimming level, and dimming transitions, all of which are managed by the systems.

For purposes of this disclosure, the terms “device(s)”, “system(s)”, and “method(s)” may be used individually, separately, conjunctively, or collectively to describe the disclosed embodiments and aspects without limiting such descriptions.

In one or more exemplary embodiments, the disclosed systems and methods provide, among other things, a sensor and control system for controlling lumen level of a luminaire, including: a dimming control configured to control a dimming level of the luminaire, where higher dimming levels result in less light (i.e., lower lumen levels) and lower dimming levels result in more light (i.e., higher lumen levels); at least one sensor such as an up looking color sensor configured to take light intensity or lumen level readings of the luminaire; a gateway configured to receive the lumen level readings from the at least one sensor and to control illumination (i.e., lumen level) of the luminaire via providing instructions to the dimming control, and; a server such as a cloud server (in certain exemplary embodiments) configured to control operation of the gateway, wherein the cloud server is further configured to correlate an initial measured lumen level reading to an initial dimming level, and the at least one sensor sends periodic lumen level readings to the server either directly or via the gateway when the lumen level readings are outside of the sensor ranges expected by the system as instructed by the server. The cloud server compares the lumen level readings received from the sensor and/or gateway to the initial correlation of the measured lumen level reading to the initial dimming level to determine whether the dimming control protocol needs to be adjusted to maintain the lumen level of the luminaire, and the cloud server instructs the gateway to adjust the dimming control to adjust the lumen level of the luminaire when the measured lumen level needs to be adjusted.

The exemplary disclosed systems and methods are configured to allow control of at least one luminaire dimming protocol in an environment, wherein the system generates a specific/required lumen level using up looking color sensors and dimming control systems in real time; wherein the at least one gateway is connected to the up looking color sensor that provides information on relative lumen intensity regardless of power consumption or dimming level, thereby allowing an accurate maintenance/control of the lumen level when the luminaire capacity is diminishing over time or changes are made between different dimming protocols in the dimming control system. The system is further configured to maintain light intensity based on information regarding light intensity and relative lumen intensity readings at different dimming levels for each luminaire with respect to the baseline reading for each of the luminaires, thereby the light intensity of each luminaire may be maintained uniformly or to maintain a desired light intensity of the environment in which the luminaire(s) are installed. Further, at least one dimming control system includes dead band areas or empty ranges through which the dimming level of the luminaire will not change—therein the dimming level has no impact on actual lumen intensity from the luminaire through these dead band areas or empty ranges. The system is further configured to control and maintain the dead band areas or empty ranges in the dimming control system.

In various aspects, the server, e.g., the cloud server can instruct the gateway to adjust the dimming control to adjust the lumen level of the luminaire so as to keep the lumen level of the luminaire constant over time or keep the lumen level of the luminaire at user-set preferences according to, for example, a dimming protocol. Additionally, the exemplary cloud server can instruct the gateway to adjust the dimming control to adjust the lumen level of the luminaire in response to pre-scheduled changes such as changes in ambient background lighting over the course of a day.

In another aspect of the exemplary disclosed embodiments, the system may determine when the luminaire/LED can no longer maintain requisite or desired light intensity and notify a user of the same via a user interface. The system measures the lumen level and when lumen performance falls below a certain level, the user will be notified that specific luminaires must be replaced in order to maintain light intensity/lumen preferences.

In another aspect of the exemplary disclosed systems and methods, new luminaires/LEDs installed as replacements can be automatically and dynamically integrated into the lighting system because the sensor subsystem, dimming controls, gateway, and other disclosed components can set, adjust, and/or maintain the new lighting devices. For example, the exemplary system may access information stored on the exemplary cloud servers that will cause the new/modified luminaire/LEDs introduced into the system to automatically adopt and adjust to previously defined user preferences.

In another aspect, the exemplary disclosed systems and methods calculate at least one of a half-life or end of life for a luminaire based at least in part on at least one of a lumen level or degradation of the lumen level of the luminaire and/or a comparison of the current lumen level at the current dimming level of the luminaire to a correlation between a previous (or initial) lumen level and dimming level. In the exemplary or other embodiments, the systems and methods include a luminaire database that collects over time information related to a luminaire including fitting and dimming components and test data, sensor reading ranges, and sensor readings from a sensor subsystem including time, lumen level, dimming level, and temperature of each reading for the exemplary server to use for predicting and generating luminaire degradation profiles over time based on the information in the luminaire database.

The disclosure also includes an exemplary method of controlling lumen level of a luminaire, by: measuring an initial lumen level of the luminaire; measuring an initial dimming level of the luminaire; correlating the initial lumen level of the luminaire to the initial dimming level of the luminaire; taking periodic lumen level measurements of a luminaire; sending the periodic lumen level measurements from a sensor to a server either directly or via a gateway; having the gateway continually adjust the dimming of the luminaire to control the lumen level of the luminaire over time, wherein the gateway sends lumen level sensor readings to a cloud server when the lumen level sensor readings are outside of lumen level sensor ranges expected by the sensor and/or gateway according to the correlation of the initial lumen level of the luminaire to the initial dimming level of the luminaire, provided by the server, and the cloud server compares the lumen level sensor readings received from the gateway to the initial (or a previous) correlation of the measured lumen level sensor reading to the initial dimming level to determine whether the dimming control needs to be adjusted to adjust the lumen level of the luminaire; and, having the cloud server instruct the gateway to adjust the dimming control to adjust the lumen level of the luminaire when the measured lumen level needs to be adjusted.

In the same or other embodiments, the system is capable of scheduling a plurality of different lumen levels associated with many different luminaires. These lumen levels can be adjusted by triggers such as time of day, environmental sensors, or dimming levels.

In another aspect of the embodiments, the system can correlate between sensors across an entire lighting system. For example, an environmental change in one location can trigger a lumen level change at a different location. The exemplary disclosed systems can detect localized lumen level changes in areas in which one or more luminaires are installed and adjust (or not) one or more particular luminaires in the area to maintain desired lumen levels in the area.

In another aspect, a known database of information is generated by luminaire manufacturers and includes lumen level information at every dimming level of a luminaire. This information, e.g. the light intensity measured at a plurality of dimming levels as provided by the manufacturer, is used as a baseline measurement. The disclosed embodiments can maintain the lumen level (to be constant over time) by changing the dimming level over time until the correct light intensity is measured with an upward looking color sensor. The embodiments thereby allow for the installation of sensors at different locations that are independent of the luminaire and allow for the use of sensors that are not calibrated to any specific luminaire and yet are able to maintain lumen level correctly over long period of times.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

Various features, aspects, and advantages of the embodiments will become more apparent from the following detailed description, along with the accompanying figures in which like numerals represent like components throughout the figures and text. The various described features are not necessarily drawn to scale, but are drawn to emphasize specific features relevant to some embodiments.

Reference will now be made in detail to various exemplary embodiments. Each example is provided by way of explanation, and is not meant as a limitation and does not constitute a definition of all possible embodiments.

The term “module” as used herein refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software that is capable of performing the functionality associated with that element. Also, while exemplary embodiments are disclosed, it should be appreciated those individual aspects of the disclosed embodiments can be separately claimed.

FIG. 1shows an illustrative embodiment of an exemplary disclosed system100.FIG. 1illustrates the environment100in which the Universal Smart Lighting Gateway (USLG)102resides. The luminaire112is a system that can be a single luminaire or multiple luminaires connected with a single common interface to power lines120,124and dimming control lines122,126. In the exemplary embodiment ofFIG. 1, luminaire112includes associated LED111. There is a power meter114that is connected electrically between the gateway102and the luminaire112on the power lines120,124. The power meter114is connected to the gateway102via the power meter interface132and can measure and communicate the electrical power drawn by the luminaire in real time.FIG. 2demonstrates the power meter114connections in more detail. There is a sensor subsystem108, typically including an up or upward looking sensor, that is connected to the luminaire112on one side and to the gateway102on the other side via either wired or wireless connections. In the exemplary embodiment shown inFIG. 1, the connection130to the luminaire112is physical and is not limited to a specific location. The location of the sensor may be different depending on where the sensor must be positioned on a luminaire to detect a lumen (light intensity) output of the luminaire.FIG. 3demonstrates one embodiment of sensor physical interfaces and connections.

With continuing reference toFIG. 1, servers such as cloud servers106in the exemplary embodiment continuously receive performance measurements—including those from sensor subsystem108—from one or more of gateways102. For purposes of this disclosure, the terms server and cloud server may be used interchangeably where a cloud server106is depicted for the exemplary embodiments but the cloud server106may also be a local server, network server, hosted server, or any server consistent with this disclosure. In the exemplary embodiments the cloud servers106reciprocally provide each gateway102with a table of reading directions that includes the correct sensor reading schedules and expected thresholds/ranges for lumens (light intensity) at specific dimming levels associated with specific luminaires112. In the exemplary or other embodiments, the gateway102and/or sensor subsystem108may report changes or deviations from this internal table to the cloud servers106. Using this method, the system further reduces the amount of information that needs to be transmitted over the gateway backhaul118. In this way the cloud server applications can control the rate of information sent by the gateway102and more accurately predict the LED111behavior via the gateway102.

In the exemplary or other embodiments, sensor readings from the sensor subsystem108and other information are sent over the backhaul118to the cloud server106at random times. Such messages may include a time stamp of the reading and the dimming level. In various embodiments, information from the sensor subsystem108or other components may be sent to the server106either directly or via gateway102, and via either wired (physical) or wireless connections. In the exemplary embodiment ofFIG. 1, the server is a cloud server106. In the same or other embodiments, servers may be local servers, network servers, hosted servers, or any other server consistent with this disclosure.

The backhaul interface118to the gateway102can be wired or wireless Local Area Network (LAN), including possibly one or more of Mesh Bluetooth Low Energy (Mesh BLE), WLAN, ZigBee, and/or Ethernet LAN. In one embodiment this interface is Mesh BLE. The gateway102is connected with a network gateway104which resides between the local networks to a wide area network (WAN)116, and via this WAN116to cloud computers/servers106for operational and management interfaces.

FIG. 2depicts an embodiment200of the USLG102.FIG. 2illustrates a soft switch202to select between different electrical dimming interfaces for the one or more luminaires112. This soft switch202may be actively used in the search for the correct protocol between the gateway102and the dimming control110of luminaire112. The protocol modules228,230, and232are the software implementation of the dimming protocols that reside in the gateway102. In one embodiment the supported dimming protocol includes several sets of protocols such as 0V-10V, 1V-10V, Pulse Width Modulation (PWM)228protocols over 0V-10V and/or 1V to 10V, a 24V DALI®230protocol, and a 5V Digital Multiplex (DMX)232protocol. The protocols' algorithms may be implemented in the Micro Controller Unit2(MCU2)204. According to an embodiment, the MCU2204is powered by the AC to DC 5V, 24V220via the power line connection240. MCU2204is also connected to a power meter114via MCU1and a Universal Asynchronous Receiver/Transmitter (UART)224. MCU2may also be connected to a Relay206and/or a Wireless Interface Module (WIM)210via a Serial Peripheral Interface (SPI) bus212. In an embodiment, the MCU2204is also controlling the Relay206that is configured to cut off current to the luminaire112upon a decision by the MCU2204. The power cutoff can be used to disconnect power from the controlled luminaire subsystem (SeeFIG. 1). In an embodiment the Wireless Interface Module (WIM)210is implemented as Bluetooth Low Power (BLE) device using Mesh BLE protocol to connect with other devices as well having SPI bus212and Inter-Integrated Circuit two-wire serial interface bus (“TWSI”)216. The WIM210may be connected to a sensor subsystem that may include a Camera Interface System (CIS)214, which in the exemplary embodiments may include an environment sensor and, for example, a Red-Green-Blue (RGB) or Yellow-Red-Green-Blue (YRGB) sensor combination device and other sensors. The CIS module214can be extended via Two-Wire Serial Interface (“TWSI”) bus226with other sensor modules. The CIS module214requires a clock, which is received via the AC Frequency to clock module interface218. The WIM210requires power, which may be received via the AC to DC 5V to 24V220via power interface line240. The AC Power 90V-240V222may be relayed to the MCU2204and from it to the soft switch202for power selection for the dimming protocol interfaces. The AC Power222is also relayed to the power meter114which measures all power delivered to the luminaire. The LNNL234depicts the physical electrical line connections.

FIG. 3depicts an exemplary embodiment300of the sensors—CIS module308or310—and the physical interface with the gateway102via a Two-Wire Serial Interface (TWSI) connection using a 6-pin FPC cable and connector306. The CIS module is physically connected somewhere on the luminaire. A CIS module308is a linear module that can be adopted to fit on devices that require a linear fitting, while the CIS module310is circular and is designed to fit circular luminaire modules. The exemplary disclosed embodiments do not limit the type of hardware/wire/bus interfaces between the gateway102and the sensor subsystem108or devices (CIS module308,310), e.g., the number of wires, the type of wires or bus connectors. The connections may be, for example and without limitation, analog interface connectors and/or electrical/digital bus connectors of any kind. The connections may be wireless connections operating according to any wireless protocol.

The CIS308and/or310may be provided with at least two or more sensors; one sensor is dedicated to environment sensing and is configured to face away or in a downward direction from the luminaire, while a second sensor is configured to face in an upward direction towards the luminaire directly. For purposes of this disclosure, the first sensor is referred to as the environment or downward looking sensor and the second sensor is referred to as the upward looking sensor, color sensor, or upward looking color sensor.

The environment sensor is configured to monitor the environment in which the luminaire(s)112or light source are installed and may be a low resolution imaging sensor which could be an array of sensors combined into a low resolution imaging device, or a single Application-Specific Integrated Circuit (ASIC) that is an imaging sensor. The environment sensor is measuring environmental parameters (discussed further below) and is/are facing away from or in a downward direction from the luminaires.

The environment sensor includes at least three different sensors in an exemplary embodiment: a low-resolution image sensor, an ambient light sensor, and a temperature sensor. In an exemplary embodiment of this disclosure, the environment sensor may include several sensors or may be a single sensor ASIC provided the environment sensor is capable of collecting enough information to measure applicable environmental parameters such as, among other things, ambient light and temperature of the environment in which the luminaire(s)112are installed that the server106will need to calculate, among other things, luminaire light intensity and adjustments, lumen degradation, and/or luminaire half-life and/or end of life. Without limitation, this disclosure collectively refers to all sensors included in the environment sensor as the “environment sensor”. Further, without limitation, in the exemplary or other embodiments the environment sensor may include any number of sensors consistent with this disclosure; for example, humidity sensors, motion sensors, infrared sensors, “footfall sensors” (to measure the number of people passing through or present in a given environment), etc.

The upward looking color sensor or combination of sensors can measure multiple color channels (e.g., Red, Green, Blue, and/or Yellow in certain embodiments) as they directly face the luminaires. The upward looking color sensor is used to measure both the color content of a light source and light intensity. Every gateway102is connected to at least one upward looking sensor that provides the light intensity of a luminaire112regardless of power or dimming level. This allows for an accurate maintenance of a lumen level when the luminaire capacity is diminishing over time as well as during changes between different standards in the dimming control. For example, the system obviates using the dimming level to calculate light intensity or lumen level because the upward looking sensor provides the light intensity of the luminaire112at the luminaire112, for direct control. The server106in the exemplary embodiment can thus correlate the dimming level of the particular luminaire to achieve the desired light intensity.

In an aspect, calibration of the color sensor(s) may be such that the depreciation of a sensor follows a known graph, which was studied for the specific color sensor (e.g., complementary metal-oxide-semiconductor (CMOS)). The sensor readings may also be normalized over time by plotting successive readings. Thus, two different color CMOS sensors that are attached to the same luminaire in different physical attachment locations on the fitting may have different absolute light intensity readings, such as for red, green, blue, and/or yellow based on their relative positions, yet the normalized values of the percent change in light intensity read by each individual sensor will be accurate. For example, red intensity is read respectively as x1and y1at each of two sensors at time t1and, at t2, x2and y2. In the example, x2/x1=y2/y1+w, where w<<1 and each sensor reads an accurate change in red intensity between t1and t2. Therefore, the exemplary systems and methods can correlate an exponential relationship between color intensity and lumen intensity of the LED, via normalization. This relationship may be known and/or calculated by the cloud server106.

FIG. 3Bshows a representative plot of the power factor and power load of a luminaire driver and luminaire combination against the dimming setting of the luminaire, where 0 is minimum dimming (i.e., the luminaire is at maximum brightness) and 10 is maximum dimming (i.e., the luminaire is at minimum brightness). The power factor is the sum of the power load on the luminaire and the driver.FIG. 3Balso shows the associated power consumption at each dimming setting. In general, as shown inFIG. 3B, the power factor significantly decreases as the dimming level of the luminaire increases and the associated power consumption decreases. The representative graph shown inFIG. 3Bindicates that the driver becomes inefficient at lower dimming levels because the power load on the driver is staying relatively constant while the amount of light varies according to the different dimming levels. The details of the depicted correlations will likely vary between different brands and types of luminaires, and even between luminaires of the same brand and type due to manufacturing tolerances.

FIGS. 3C-3Gdepict various representative dimming curves for a luminaire/luminaire driver combination including a dimming control/circuit. Unlike a switching circuit where a light level can be toggled directly between 0% output (off) to 100% (on), a dimming circuit can vary the light output between minimum and maximum outputs. The light level produced at different dimming levels depends on a number of factors including, but not limited to, the brand and type of the luminaire and/or luminaire driver, the conditions of the environment in which the luminaire is installed, and the dimming protocol according to which the luminaire driver is operating. For example, the dimming devices may not necessarily dim to 0% output, such as in the case of 1-10V dimmers, which typically require a switching circuit to reach 0% output. Various luminaires and/or luminaire drivers on the market may state the lowest dimming value that the luminaire or luminaire/driver combination can output according to their dimming protocol, which may be one or more of any number of, e.g., analog or digital LED lighting control protocols. Each such protocol will dim the lighting in a particular way and the dimming profile may be represented graphically as dimming level versus light output. Certain representative dimming curves are shown inFIGS. 3C-3Gand explained further below. InFIGS. 3C-3G, dimming levels increase in a direction from 0 to 100; that is, a dimming level of 0 is a minimum dimming (maximum brightness of the luminaire) and a dimming level of 100 is a maximum dimming (minimum brightness of the luminaire).

FIG. 3Cshows Signaled (S) Curve dimming. A representative S Curve will be either a digitally-set dimming curve or the result of a PWM dimming protocol, e.g., for an LED light source. PWM dimming is typically found in DMX lighting control and/or systems where the dimming control is driven by a Triode for Alternating Current (TRIAC), Metal-Oxide-Semiconductor Field-Effect Transistor (MOSFET), or a similar gate/timer device for high voltage/current LEDs. PWM has a greater biological effects of flicker due to the switching frequency of the PWM. For example, the flicker may cause psychological issues for humans and growth problems in plants.

The S Curve (sigmoid curve) is calculated as follows:

FIG. 3Dshows a DALI® dimming curve according to the DALI® Standard (International Electrotechnical Commission (IEC) 62386). DALI® dimming commands are sent to the LED driver as a digital 8-bit number and follow a logarithmic dimming pattern. The logarithmic approach factors in an aspect of the Weber-Fechner Law: to the human eye a dimming curve such as shown inFIG. 3Dwill be perceived as a linear increase of light output, as represented by the dotted line. To normalize the DALI® dimming commands against other dimming curves, the 8-bit command may be converted to a percentage dimming value. The DALI® Logarithmic Curve is calculated as follows:

FIG. 3Eshows a representative linear dimming curve. A linear dimming curve as shown inFIG. 3Eis calculated as follows:
Y=X(eq. 4)
where X=Dimming Value (%)

FIG. 3Fshows a square curve dimming profile. A square curve as shown inFIG. 3Fis calculated as follows:

FIG. 3Gshows a representative linear Dead Band dimming curve. Dead Band refers to dimming levels at which the dimmer is adjusted but there is no (actual or perceived) change in brightness of the luminaires/LEDs. As shown inFIG. 3G, Dead Band can occur at both the low and high end of the dimming range. Dead Band may also occur in the middle of the dimming range (referred to as Dead Travel), although this is not depicted in the representative curve shown inFIG. 3G. Unintended Dead Band/Travel may be the result of any number of factors affecting the electrical and mechanical aspects of the luminaire/driver including, but not limited to, the brand and/or type of luminaire/driver, conditions in the environment in which the luminaire/driver is installed, voltage of the power source supplying the luminaire/driver, and the elapsed life and number of dimming cycles that the luminaire/driver has experienced. Dead Band and/or Dead Travel may affect analog or digital dimming controls including the DALI® and 0-10V LED drivers mentioned above. Dead Travel is more typical of resistive dimming devices but can be found in digital systems dependent on driver performance/quality.

Within a lighting installation, many luminaires having a variety of different dimming curves may be present across the same or different spaces. Accordingly, identifying and normalizing all the dimming curves will be essential to ensuring smooth lighting installation and operation. For example, maintaining a desired light level or color temperature in a room with multiple luminaires depends on correlating changes to the overall light level or color temperature to a potential change in the dimming level of any particular luminaire. As shown inFIGS. 3C-3G, the same percentage change in dimming level for different luminaires having different dimming curves may result in incongruous changes in light level or color temperature contributed by each luminaire.

There are a variety of fixed dimming curves available and different control protocols and/or LED drivers that will follow their manufacturer's set profiles. The curves inFIGS. 3C-3Gare illustrative and the nature of a dimming curve for any particular luminaire or luminaire/driver combination may not follow those figures. For example, some device(s) may have a driver-specific, irregular curve as a result of resistive and/or TRIAC dimming of LEDs. As described further below, the exemplary disclosed embodiments normalize the various dimming curves of luminaires/drivers across a lighting system and therefore provide dynamic control over each luminaire/driver and the spaces in which they are installed to maintain, e.g., light levels or color temperature and maximize the life of the luminaires/drivers.

With reference now toFIG. 3H, a representative correlation between measured and perceived brightness is shown. The human eye does not respond linearly to light. If a luminaire utilizes a true linear dimming curve, the typical observer will see significant changes in brightness during the first 50% of the dimming range, e.g., as dimming is decreased from 100%, but fewer changes in brightness during the last 50% of the dimming range. The relationship between measured versus perceived brightness as shown inFIG. 3H, is approximately:

With reference now toFIG. 3I, a test was conducted using an eldoLED-brand LED driver that can be programmed to output both logarithmic and linear dimming curves to view the differences between logarithmic and linear dimming as shown inFIG. 3I. Luminaire, power monitoring and control devices all remained the same between the two dimming protocols. All values were normalized for representation on a single plot, and perceived brightness was calculated and added to the plots. Analysis of the perceived brightness versus power consumption was conducted to ascertain the efficiencies of each of the dimming curves and a ratio was calculated as follows:

Light⁢/⁢PowerRatio=NormalisedPerceivedBrightnessNormalisedPowerConsumption(Eq.⁢7)
Table 1, below, summarizes the results of the light/power analysis at various dimming levels for each of the logarithmic and linear dimming curves.

Further analysis of the two representative dimming curves as shown inFIG. 3Jshows that a log dimming curve is slightly more efficient (more light per unit power) in the lower regions of dimming but a linear curve has more efficient performance in the higher dimming region for this particular driver. Nonetheless, each curve may be suited for particular applications. For example, hospitality and retail spaces may find the smooth high-end dimming of the logarithmic curve beneficial over the drop-off in light observed for the linear curve.

In typical commercial lighting installations, driver dimming/mapping will either be linear or logarithmic. Other types of dimming curves are typically found in particular applications such as entertainment lighting. Linear curves are typically more efficient while logarithmic curves allow for a smoother curve and feel to the dimming. In the disclosed exemplary embodiments, the power meter114and up looking color sensor may asses a luminaire/LED driver's dimming capabilities and modify the driver's dim settings using a software interface to achieve a desired light output, color temperature, efficiency, etc. correlated to other luminaires/LEDs in the lighting system. In an exemplary smart lighting installation, the dimming control signal will be a digital 0-100 value representing the dimming level or percent (e.g., with zero representing the minimum dimming level (maximum brightness) and 100 representing the maximum dimming level (minimum brightness)) and this will be consistent across all dimmers. Accordingly, the exemplary disclosed embodiments provide enhanced control over uncorrelated manual resistive-type dimmers that have manufacturing inconsistencies and digital dimmers with unique curves. The exemplary software interface is capable of characterizing light output, power, current, and power factor at all dim levels for all luminaires within a control group; this allows the dimming curve, dead band, and energy consumption of the luminaire to be identified. Using this data, the software interface can remove any dead band from the dimming range and set the measured brightness to follow a desired curve such as, for example and without limitation, linear perceived brightness, best fit for energy efficiency, etc. As the user then dims from 0-100, there will be a linear decrease in brightness.

The dimming range mapping can also take into consideration any global max dim values set for a product or group of products. For example, if an estate manager wanted to save 5% on energy across a lighting system, this may require more than a simple 5% change to each luminaire's dim settings because, as noted above, the same change in dimming percent across multiple luminaires may not result in equivalent changes to light output, power consumption, etc. due to the potential differences between each luminaire's dimming curve. In the case of disclosed curves inFIGS. 3I and 3J, a 5% dimming change for a logarithmic curve may result in approximately 14% energy savings, while the linear curve may realize only approximately 3% energy savings. As a further example, a simplified lighting system for a space may include two luminaires having different maximum brightness values and drivers having different dimming curves. Without correlating the light output and dimming curves of the two luminaires/drivers, the overall illumination in the space will not linearly follow corresponding changes to either or both luminaires because each luminaire is contributing to the overall illumination according to a particular maximum brightness and dimming curve. On the other hand, in the exemplary disclosed embodiments the dimming curves of luminaires112/drivers across a lighting system are correlated such that, in part, the overall light output, perceived brightness, color temperature, power consumption, etc. of a group of luminaires112can be controlled across the group and in view of any changes to associated parameters of any individual luminaire112.

Further, and as described further below, as the luminaire and/or driver ages, the dimming range mapping will likely require updating to account for the luminaire degradation and driver performance. The iterative dimming range mapping at various times throughout the life of the luminaire/driver may also provide data for predicting a half-life or end of life for the luminaire/driver, based on, e.g., the rate of degradation. Other factors such as the occurrence of dead band or dead travel may be used as additional metrics for predicting failure of the driver. The exemplary disclosed embodiments may be configured to use such information in adjusting the dimming level and/or dimming protocol of a luminaire/driver to maximize the life of the component.

Applying the previously mentioned software implementation to adjust the dimming characteristics of a driver can be applied to both a retrofit WIM and integrated core module situation. The software may be configured to handle the dimming curves for multiple LED lighting devices/drivers and thereby simplify the system design. Typically, one type of driver may be used with any number of combinations of luminaires from different manufacturers. The load of the luminaire on the driver will differ from product to product, which will in turn change the performance of the dimming of the system. The software implementation may adjust and compensate the dimming to the load attached to each driver. The software implementation may also calculate the most efficient dimming curve(s) to use with a particular luminaire/driver, as particular drivers may show different efficiencies depending on the dimming curve(s) that they are handling.

In the exemplary or other embodiments, manual control may be substituted for certain software-based implementations where consistent with this disclosure.

FIG. 4depicts one exemplary embodiment400in which the system operates at a high level. The cloud server106is in a reactive mode, checking regularly for events404.FIG. 4depicts three different types of exemplary events408,412, and418. The first event408is “Device is initializing” which is handled by the “Handle device setup and discovery”410. The details for these interactions are described inFIG. 5. The second type of event is a “Baseline message received”412. A Baseline Message may include, for example and without limitation, full sensor readings from sensor subsystem108, power level readings from power meter114, and the current dimming state for the luminaire112. The handling of a Baseline Message is described inFIG. 6for the gateway102. Finally, a third type of event is associated with an “Updates message received.” Handling420for the Updated message418is described inFIG. 7. An Updates Message may include, for example and without limitation, changes or differentiations from a previous message set, where a message set can be a baseline message set or any of the updates message set relating to, e.g., sensor readings, light intensity of the luminaire112, power consumption of the luminaire112, dimming level of the luminaire112, etc. After handling incoming messages of any type, e.g., Baseline messages or Updates messages, the corresponding updates or changes (as discussed above) are recorded in a Luminaire and Driver Database (DB)416. The handling of device setup and discovery is also recorded in the Luminaire and Driver DB416as depicted inFIG. 6.

After the handling of Baseline412and Updates418messages, the exemplary system at the server106will predict the luminaire half-life, or end of life, or adjust its previous predictions422. At step428, the system lets the lumen level handling control process know that an event has occurred, which may have changed the lumen level for a specific luminaire112. Step428may entail adjusting the dimming level to adjust the lumen level of the luminaire112and is described in further detail inFIG. 15. Changes in the dimming level, schedule, or protocol of a luminaire will have impacts on its predicted half-life; therefore, over time and based on usage, the predictions will change based on the information that is received by the server106and Luminaire and Driver DB416over time.

At step402, system operations initiate. At step404, the system (i.e., the cloud server106) checks for events that need to be handled. If there are events that need to be handled by the system, the operation goes to step406. If there are no events that need to be handled by the system, the operation goes to step424in which the system goes into a waiting, or “sleep” mode.

FIG. 5depicts an embodiment500of the system handling of device setup and discovery operations. The first event after turning on a gateway102will be a request for information (RFI)516from the gateway102to the cloud server106. The initialization information518may include, for example and without limitation, information regarding the type of luminaire112, applicable dimming profile for the luminaire112, lumen (light intensity) ratings for the luminaire112, etc. Based on the information518, the gateway102will set the appropriate dimming protocol for the luminaire and send a Ready message520to the cloud server106. The Ready message520includes information identifying the luminaire112, its dimming protocol, and sensor information as collected during the dimming protocol test/discovery506by the gateway102. The cloud server106will respond with dimming and sensor information522associated with the setup of the sensors for baseline and for tune-up508. The gateway102will then collect the readings of the sensors and set the luminaire to the baseline or predefined states510of, for example and without limitation, the light intensity and dimming level of the luminaire112. The information collected is sent to the cloud server as part of Sensor Readings message526. The cloud server106uses the Sensor Readings information526from the gateway102to store the baseline states and determine a sensor measurement schedule512for the luminaire112. The cloud server106then sends back to the gateway102any additional information that has been gathered since establishing the baseline states and a schedule for dimming and measuring the luminaire112as a Future Reading Schedule528. The cloud server106will commensurately update the Luminaire and Driver DB416with information regarding the luminaire112, such as discussed above, and continue to System Operations402. The gateway102receives and sets the scheduled dimming and reading information for the luminaire112, records the same in the Dimming & Testing Schedule DB524, and continues to the Standard Operational Mode530(FIG. 6).

In another aspect, the gateway102can be controlled such that it executes measurements, or instructs the sensor subsystem108to execute measurements, for example and without limitation, only when environment conditions are in a certain range and/or when the dimming level of the luminaire112is in a certain range. These instructions and other control of the measurement schedules and protocols are provided to the gateway via the cloud servers106which are connected to the gateway102in the exemplary embodiment shown inFIG. 1.

FIG. 6depicts an embodiment600of the handling of the gateway102Standard Operational Mode530. The gateway102is in a waiting, or “sleep” mode, until a scheduled or sensor event is initiated604. The events can be one of two types: the first type is associated with an existing dimming level and sensor reading test604, e.g., at a specific time when a specific dimming level is set for the luminaire112and sensor readings are taken by sensor subsystem108. For this event, the gateway102will set the dimming level to the requested dimming level and receive the sensor readings606. The sensor events are monitored for storage in the Sensor Events DB612. The second type of event is a sensor reading608that is present and needs to be read and processed. In one embodiment, the gateway102does not automatically initialize to process or handle events that are not planned for, e.g., scheduled. After the initialization of the gateway102, the gateway102will receive a scheduling message from the cloud servers106. This message will include parameters to populate the dimming & test schedule Database524. The Receive scheduling and parameters updates622process will update the Dimming and Testing schedule database524and also refresh the sleeping timer to wake on the next appropriate test schedule. If or when a scheduled test is triggered, the gateway sets the dimming to the requested light percentage and the monitoring sensor event610process is updating the sensor events database612and goes to sleep602until the next scheduled/sensor event.

On the other hand, a non-scheduled event is something that happens at the sensor (step608). The event may be a change in lumen level or dimming level of the luminaire. The sensor sends the information to the gateway102, which determines based on the standard operational mode530whether a Baseline and/or Updates message is required in light of the sensor event. If so, the gateway102sends the information to the server and Luminaire and Driver DB416as a Baseline or Updates message.

According to the exemplary embodiments, a scheduled dimming level and sensor reading test604includes a plurality of sensor readings such as, for example and without limitation, measuring light intensity and/or environmental conditions, waiting for the lumen or light intensity readings for the luminaire112to reach a specific level/range, waiting for the ampere (AMP) reading to reach a specific range of power consumption of the luminaire112, and reading light intensity for a plurality of colors multiple times. When a sensor event608occurs there can be multiple outcomes, such as explained with respect toFIG. 4. If the sensor reading is the last sensor reading required for this specific scheduled dimming measurement, the gateway102can make a decision if the set of measurements requires a new Baseline message614or an Updates message (FIG. 7) based at least in part on a threshold deviation from a previous or initial sensor reading for the luminaire112. In the case of a Baseline message, the gateway102will format a new Baseline message, send it to the cloud server106, and update the message status database616to wait for the next event.

The handling of Updates message is covered inFIG. 7, described further below. In any case, after an Updates message is handled the gateway102can go back to a waiting, or sleep, mode.

A third case is when there are more events associated/chained to the current scheduled dimming that the gateway102must wait for, for example scheduled dimming level and sensor reading tests604. In this case, the gateway102waits for those events in an effective sleep mode. Current events in the exemplary embodiment shown inFIG. 6are always recorded in the Sensor Events DB612, where all accumulated and scheduled events and/or resultant information are recorded for future processing.

Thus,FIG. 6depicts the USLG gateway standard operation mode530as follows: At step602, the gateway102spends most of its time sleeping and waiting for an event. At step604, the gateway102checks for any triggered scheduled tests, which are waiting in the Dimming & Testing schedule database524. If ‘Yes’—a test is triggered, then the operation moves to step606where the gateway102sets the dimming protocol to the requested dimming level and receives relevant measurements from the sensor(s). After step606, the gateway102performs step610where the gateway102starts to monitor sensor events. For every event that occurs, the operation moves to step612where the gateway102updates the sensor events database. Note that monitoring sensor events occurs in parallel/in the background by step610and the rest gateway102also moves to step602where the gateway102again waits for an event to occur.

If at step604there is no scheduled testing event waiting, e.g., ‘No’, then the operation moves to step608, where the gateway102checks for any triggered sensor events as previously described. At step608, the gateway102checks for any triggered sensor events. If the response is ‘Yes’, then the operation moves to step614. If the response is ‘No’, then the operation goes back to step602and waits for an event to occur. At step614, the gateway102decides if the sensor reading requires a baseline messages. If the response is ‘Yes,’ then the operation moves to step616. If the response is ‘No’, then the operation moves to step620. In one embodiment, the decision is based on multiple factors, but mostly on any changes between a previous baseline message and what would be a current baseline message, as well as when there is no prior baseline message, and/or a change in the dimming level.

At step616, gateway102sends baseline message to the server106and then moves to step618where the message status database gets updated. When there is no need for a Baseline message but a need for an updates message, the gateway102goes to step620. When message generating is done, the gateway102moves to step602and waits for the next event.

FIG. 7depicts one exemplary embodiment700of creating Updates message as follows. Creating an Updates message depends on the accumulation of all prior messages sent and recorded in the Message Status DB618. Based on past messages, including, among other things, sensor readings, dimming levels, light intensity, etc., and current corresponding information from the Sensor Events Database612, the gateway102can identify sensor readings702that have changed704and can format a message to include those readings706only and send this message to the cloud server106. Once this message is sent, the Message Status DB618is updated for future analysis of changes in, for example, the information identified above, and the gateway102waits for the next event as part of the standard operational mode530. In an exemplary embodiment, Updates message(s) may also be sent at regular time intervals and sensor readings from sensor subsystem108can be averaged over the time interval.

At step702, the gateway102receives messages from Message Status DB618to, among other things, identify the last Baseline message and Updates message(s) that had been sent. At step704, after receiving information from the Sensor Events DB612, gateway102identifies which of the events have been triggered and what changes have taken place in the values for the appropriate sensors versus the previous Baseline/Updates message(s) received from the Message Status DB618. At step706, the gateway102generates an Update message, which includes the difference(s) between last sent Baseline message(s) and the Updates message including the current information, such as sensor readings from Sensor Events DB612. At step530, the gateway102moves into standard operational mode530. At the same time, at step706, the gateway102updates the Message Status DB618.

FIG. 8depicts an exemplary embodiment800of at least one cloud server calculating specific luminaire half-life prediction information. In order to calculate luminaire degradation, upward looking color sensors provide light intensity and/or luminosity readings/measurements that are linearly correlated to a luminaire light intensity depreciation graph (FIG. 8A). The linear correlations are normalized over time in this embodiment and the color sensors are consistent in their readings across a plurality of sensors such that when an LED light intensity reading is changing by X %, the sensor light intensity reading changes by the same X %. The sensor ‘total intensity readings’ may not be equivalent to the actual lumen emission by the luminaire device that the sensors are attached to due to any number of factors such as distance or orientation of the sensor to the light source, interference, baseline readings of lumen intensity at initialization of the lighting system etc. The disclosed systems and methods allow the light intensity of each luminaire to be accurately correlated at any given time, regardless of the type of luminaire, because the data is dynamic and normalized. The normalized, linear correlations also provide compensation for differences between different types of dimming controllers (drivers) and inherent variations in tolerances of the same dimming controllers.

When exponential graphs are linearly correlated, a change in one (the curve) can fit the curve (change) in the other directly. Illuminating Engineering Society of North America (IESNA) Standard LM-80 (“Approved Method for Measuring Lumen Maintenance of LED Light Sources”) includes manufacturing data for a plurality of LED light sources, which when paired with a luminaire's chip running temperature can provide theoretical predictive life calculations. By testing the luminaire to IESNA LM-79 (“Approved method for the Electrical and Photometric Measurements of Solid-State Lighting Products”) standards and utilizing any IESNA Standard LM-82 (“Characterization of LED Light Engines and LED Lamps for Electrical and Photometric Properties as a Function of Temperature”) data that may be available, a Luminaire and Driver DB416may be generated. The Luminaire and Driver DB416includes information that is specific to the luminaire fitting and dimming profile/protocol, as well as to the sensor reading ranges, etc., associated with the specific luminaire. The Luminaire and Driver DB416also includes information such as past sensor readings, associated times of reading, dimming level, temperatures, current readings, etc. Sensor readings such as light intensity, among others, can be normalized based on the original (initial) readings received upon installation and/or commissioning of the luminaire in the lighting system as inFIG. 5.

In one embodiment, an Energy Star® TM-28 calculator, which is the equivalent of an Illuminating Engineering Society (IES) TM-21 (“Lumen degradation lifetime estimation method for LED light sources”) calculator806, is taking data that was collected over time in the Luminaire and Driver DB416for test samples and is plotting this information after normalization into TM-28. This step allows for prediction of luminaire maintenance over time. The standard information within LM-80 given by the manufacturer may be insufficient and is dependent on a fixed temperature and the current state of the luminaire for the readings. In one embodiment, the disclosed system is using the sensor readings at specific temperatures and dimming levels to extrapolate the place of the luminaire light intensity readings on the LM-80 given curves of this specific luminaire. Using this information, and knowing the time period elapsed between readings, and after correlating this information with previous readings, the system can extrapolate a new curve that more accurately represents the current luminaire's behavior. As such, the relationship or correlation between light intensity and dimming level can be determined, and this relationship can be updated over time as the light intensity (lumen level) of the luminaire degrades over time. This new curve is based on the luminaire's true environment and usage (e.g., dimming schedule, power and temperature levels, degradation of the lens and the physical fittings, etc.) over time. This information is stored in the Luminaire Half-life Prediction DB810for future use, and the next step is to wait for the next event as part of the System Operations402(FIG. 4).

The multiple sensor readings associated with light intensity are normalized using an equation that divides the current reading by the initial reading taken when the luminaire was first installed and/or commissioned in the lighting system as inFIG. 5.

According to an aspect, the luminaire112and dimming control110half-life adjustments/end of life predictions begins at step802, where the cloud server106receives from the sensor subsystem108, gateway102, power meter114, and other system components light intensity, dimming level, power consumption, and environmental information for a specific luminaire112at a specific power level and temperature. In an embodiment, step802occurs after the cloud server106has received information from the LM-80 Luminaire DB812and the Luminaire and Driver DB416. The Luminaire and Driver DB416may include information specific to the fitting and dimming, as well as to the sensor reading expected ranges, associated with the specific luminaire112. According to an aspect, the Luminaire and Driver DB416may also include all past sensor readings, with the associated times/time stamps of the reading(s), dimming levels, temperatures and current readings that were taken. In an embodiment, the sensor subsystem108, temperature, and current readings regarding, e.g., light intensity, dimming level, environmental conditions, etc., can be normalized based on previous and/or the original readings taken upon installation of the luminaire112, as shown in the setup and discovery operations inFIG. 5.

At step802, the cloud servers106may read information received from Driver Manufacturers DB812(LM-80 Luminaire DB) and the Luminaire and Driver DB416for the specific luminaire112. The information may include the specific power levels and temperatures as well as the sequence of temperature changes acting upon the electronic dimming control110. According to an aspect, the Luminaire and Driver DB416includes information that is specific to the luminaire, the dimming control110and the dimming level, as well information that is specific to the expected ranges of the sensor readings of the specific luminaire112. As described in further detail hereinabove, the Luminaire and Driver DB416may also include all past readings with associated time stamps, and may normalize the readings based on the original (initial) readings received upon installation of the luminaire112, for example the lumen intensity and dimming level. At step804, the cloud server106may decide if the collected and/or accumulated information/readings from, e.g., LM-80 Luminaire DB812and Luminaire and Driver DB416, are sufficient to continue with half-life prediction and/or end of life calculations. If the response is ‘No’, then the operation moves to step402, which is the system operation main loop where the cloud server106will wait for and continue to collect information and measurements from the sensor subsystem108, gateway102, power meter114, and other components of the exemplary system100. If the response is ‘Yes’, then the operation moves to step806.

At step806, the TM-28 luminaire equivalent of the IES TM-21 calculator takes data that was collected over time in the Luminaire and Driver DB416to create a test sample. The data for the test sample may be plotted in a graphical format, after normalization of the data into the TM-28 luminaire. According to an aspect, this step allows for the prediction of lumen maintenance over time, which helps to predict potential failure of the luminaire112. At step810, the information generated in step806is stored in the Luminaire Half-Life Prediction DB810for future use, thus the system100may retain the information and use the information to create further end-of-life predictions based on failure variable indications of the dimming control110and, optionally of the luminaire112.

FIG. 9depicts an embodiment900of the sensor interface data structures. The sensor interfaces include the Sensor Global Configuration Registers Interface902, the Environment Sensor Configuration Registers Interface904, and the Color Sensor Configuration Registers Interface906. In one embodiment, these data structures are memory mapped registers. To send information via a memory mapped register the application writes to the memory address that was allocated for this register. To receive information, the application reads the memory address that was allocated for the specific register. InFIG. 9the relative address of the register is marked in boxed brackets ‘[ ]’. The size of every address is exactly one byte (eight bits) in the exemplary embodiment shown inFIG. 9.

The Sensor Global Configuration Registers Interface902includes a plurality of global configuration registers responsible for performing a plurality of activities. Available Sensors—e.g., [0x01]908—shows which sensors are available for the particular device. The Available Sensors may show at least a Temperature Sensor (TEMP), an Ambient Light Sensor (ALS), a color sensor (RGB), a Motion detector sensor based on Passive Infrared (PIR), a Motion detector and direction sensor based on frame capture, and so on. Sensors Alarm—[0x02]910shows which sensors have generated an interrupt. Sensors Alarm Interrupts—[0x03]912enables/disables interrupt from each available sensor whenever an alarm is generated. Power Management—[0x04]914controls power up/power down functions for the different sensors. Configure Management—[0x05]916stores register values in non-volatile memory. Hardware Register Access Address (HRAA)—[0x06]918holds the address for accessing the internal hardware registers of sensors. Hardware Register Access Data (HRAD)—[0x07]920holds the data to load/store in the address given in the register HRAA—[0x06]918. Direct Hardware Register Access RW—[0x08]922, if it holds a value “1”, then the data in the register HRAD—[0x07]920is written to the address in register HRAA—[0x06]918. If Direct Hardware Register Access RW—[0x08]922holds a value “0”, then the data pointed to by register HRAA—[0x06]918can be read in register HRAD—[0x07]920.

The Environment Sensor Configuration Registers Interface904includes a plurality of environment specific sensor registers. Ambient Light Sensor (ALS) Range—[0x20]924, if it holds a value “1”, enables a high measurement range of 1000-10,000 Lux for the ALS. If ALS Range—[0x20]924holds a value “0”, then a low measurement range of 1-1,500 Lux gets enabled. ALS Measurement Interval—[0x21]926displays the elapsed time between subsequent ALS measurements. ALS Lower Threshold MSB—[0x22]928displays Most Significant Byte (MSB) for ALS lower threshold for triggering an alarm. ALS Lower Threshold LSB—[0x23]930displays Least Significant Byte (LSB) for ALS lower threshold for triggering an alarm. ALS Higher Threshold MSB—[0x24]932displays MSB for ALS higher threshold for triggering an alarm. ALS Higher Threshold LSB—[0x25]934displays LSB for ALS higher threshold to trigger an alarm. ALS Result MSB—[0x2A]936displays MSB for ALS measurement results. ALS Result LSB—[0x2B]938displays LSB for ALS measurement results. TEMP Threshold—[0x90]940displays upper threshold value for when an interrupt is triggered. TEMP Measurement Interval—[0x91]942displays a temperature measurement interval in seconds. TEMP Data—[0x92]944displays temperature values in degrees Celsius.

The Color Sensor Configuration Registers Interface906includes a plurality of color specific sensors. In one embodiment, the colors are Red, Green and Blue (RGB). RGB Conf.—[0x50]946controls both calibration configuration and reports when a sensor reading is available. RGB Red Cal.—[0x51]948displays calibration constant for red value from RGB sensor. RGB Green Cal.—[0x52]950displays calibration constant for green value from RGB sensor. RGB Blue Cal.—[0x53]952displays calibration constant for blue value from RGB sensor. Red Value MSB—[0x54]954displays MSB result of Red value from RGB sensor. Red Value LSB—[0x55]956displays LSB result of Red value from RGB sensor. Green Value MSB—[0x56]958displays MSB result of Green value from RGB sensor. Green Value LSB—[0x57]960displays LSB result of Green value from RGB sensor. Blue Value MSB—[0x58]962displays MSB result of Blue value from RGB sensor. Blue Value LSB—[0x59]964displays LSB result of Blue value from RGB sensor. Any of a plurality of colors can be used for light intensity measurements. The sensor chosen depends on the LED/luminaire color utilization. Luminaire devices may have design based or physics based preferences to emit specific colors; the color sensor used in every specific case should be based on those preferred colors. The RGB given in this example is based on one embodiment; other embodiments may use other colors.

FIG. 10depicts an embodiment1000of message structure for messages delivered from the gateway102to the cloud server(s)106. In one embodiment, the message1002going to the cloud server106is of a single structure. This structure includes Message type1004, the sender gateway unique identification (Source: gateway ID)1006, a unique Reference ID1008and the Message body1010. The Message type1004informs the receiver about the type of the message. The reference ID1008is an internal number used when there is a conversation between the cloud servers106and the gateway102. The message body1010can be a Baseline message or an Updates message and it is structured the same in both cases.

In one embodiment ‘Message types’1004can be a ‘Request for Information’ (RFI)516, which is sent upon initialization of the luminaire. A ‘Ready’ message520is sent during initializations of the luminaire after discovering the dimming protocol and when the gateway102is ready for further instructions. Sensor readings message526is sent to the cloud servers106during the initialization period. The ‘Baseline’412and the ‘Updates’418message types are used when sending Baseline or Updates messages that are based on cloud servers'106prior scheduled sensor readings by the specific gateway102.

In one embodiment, the ‘Baseline or Updates and Sensor Readings Message’1030is a ‘Message body’, which is sent for the Baseline412, Updates418and sensor readings526message types. The message stature is the same. For every ‘action’1012, which can be a dimming level set, there is ‘Start’1014which is the actual start time, ‘End’1016which is the time the action was terminated, ‘Reason’1018which is why the action terminated, and sensor readings526for all sensors participating in this action as they were scheduled by the cloud server106. The ‘Reason’1018why the action terminated can be, e.g., failure to obtain an accurate feedback dimming level.

The Sensor reading526part of the message includes a ‘Sensor type’1020field to indicate which sensor reading this is (TEMP, ALS, RGB, etc.), a ‘Time taken’1022field to indicate when it was taken, and a ‘Vector of readings’1024which includes multiple readings centered around the ‘Time taken’1022field. In one embodiment, the number of readings can be based on the sensor type. In another embodiment, the number of readings is three, including shortly before, at, and shortly after the ‘Time taken’1022field value.

FIG. 11depicts an embodiment1100of message structure for message delivered from the cloud server(s)106to the gateway102. In the exemplary embodiment, the structure of the message1102is constant. This structure includes Message type1104, a target gateway unique identification1106, a unique Reference ID1108and the Message body1110. The Message type1104lets the receiver know what kind of message it is. The reference ID1108is an internal number used when there is a conversation between the cloud server106and the gateway102. The Message body1110is a Sensor Reading Schedule528(seeFIG. 5) in the exemplary disclosed embodiment.

In one exemplary embodiment, the Message types1104are ‘Information’518, ‘Sensor Setup Info’522and ‘Test Schedule’1112. The ‘Information’518, such as the ‘Sensor Setup Info’522messages provides the gateway102with information about valid ranges for sensor readings at different dimming levels. The Message body1110is a Sensor Reading Schedule528that is a baseline for the gateway102in its internal measurement and initialization cycle. The gateway102will have a default setup, yet this message can update this default.

In one exemplary embodiment, the Sensor Reading Schedule528includes an ‘Action’1120field, which is the dimming level, the ‘Start’1122field, which is the start time for the test, the ‘Wait’1124field which is the duration to wait before any measurement commences, followed by a list of sensors that participate in the measurements1126. The list of sensors is given as a list of Sensor ranges per sensor1126.

In one embodiment, the Sensor range1126includes ‘Sensor Type’1156field, which identifies the sensor, ‘Test Type’1158field, which informs the gateway102how to run the test, and ‘Min Value’1160and ‘Max Value’1162fields, which provide the valid range for the sensor in this test. In one embodiment, the ‘Test Type’1158directs the gateway102in ways to handle different sensor values. When Test Type1158is ‘Read Only’1166the value of the sensor is retrieved regardless of range. When Test Type1158is ‘Outside of Range’1168the value of the sensor must be outside of the range to be retrieved. When Test Type1158is ‘Wait for in range’1170the gateway102does not continue with other readings until the specific sensor is in given range. When Test Type1158is ‘Wait for outside range’1172the gateway102will not continue to read sensor values until this sensor value is outside the given range.

FIG. 12depicts an embodiment1200of the Luminaire and Driver DB416structure. In one embodiment, the Luminaire and Driver DB416includes three types of records for every connected luminaire in the system. The records are: Sensor Baseline Information1202, Sensor Reading Schedule1212and Sensor Reading Result Record1228. There is a single Sensor Baseline Information1202and Sensor Reading Schedule1212record per luminaire. The Sensor Reading Result Record1228is numbered between 1 and N. This type of record is being added for every measurement result, such as, among other things, light intensity, dimming level, environmental conditions, time stamps, and other disclosed measurements/readings, and is kept for as long as the system needs such information to determine half-life and end of life information for the luminaire112.

In one embodiment the Sensor Baseline Information1202includes sensor range information for all possible dimming levels that might be tested for this specific luminaire. Each dimming action field1206includes the minimal Wait time1208, which the gateway102must wait before taking sensor measurements, and a list of Sensor range fields1210, one per sensor that needs to be monitored. The Luminaire ID1204field is for identifying the luminaire that the record belongs to.

In one embodiment, the Sensor Reading Schedule1212record is identical to the Sensor Reading Schedule528as described inFIG. 11, except for one additional field—the Luminaire ID1204field that is used to identify the luminaire to which the record corresponds.

In one embodiment, the Sensor Reading Result Record1228is an accumulation of the Sensor Reading Message1030as described inFIG. 10, except for one additional field—the Luminaire ID1204field which is used to identify the luminaire that this record belongs to. In fact, every time the cloud server106receives a Sensor Reading Message1030that might be a Baseline message or an Updates message, the cloud server106will store this message as a Sensor Reading Result Record1228for the specific luminaire.

FIG. 13depicts an embodiment1300of the Sensor Events DB612and the Message Status DB618structures. In one embodiment, as disclosed inFIG. 6, the Message Status DB618is an accumulation of all sensor events associated with the reporting of scheduled test results. The Sensor Events DB612is used to record events in real time such that the information is recorded into the appropriate structures for future messages to be generated. In one embodiment, the Message Status DB618contains two records. The first record is a Sensor Readings Message Status Previous View1302, and the second record is the Sensor Readings Message Status Current View/Current Events Status1314. When reading events are triggered, the appropriate fields in the Readings Message Status Current View/Current Events Status1314record are updated. When an Updates message is being sent or before a Baseline message is being sent, the content of the Sensor Readings Message Status Current View/Current Events Status1314is copied into the Sensor Readings Message Status Previous View1302. When a Baseline message is being sent the entire Sensor Readings Message Status Previous View1302record is being sent as is. The detailed description of the Sensor Readings Message Status Previous View1302and the Readings Message Status Current View/Current Events Status1314can be found inFIG. 10under Baseline or Updates and Sensor Readings Message1030.

FIG. 14depicts an embodiment1400of the Luminaire Half-Life Prediction DB810structure. This database is a log for all Normalized Light Intensity or Lumen Level Measurements per luminaire in the system. Every Light Intensity Log1402record (one per luminaire) includes the Luminaire ID1204field to uniquely identify the luminaire that this record belongs to. The Light Intensity Log1402record is composed of N Normalized Light Intensity Measurement1406records one per Date/Time in which this measurement was received. In one embodiment, the Normalized Light Intensity Measurement1406record is composed of a list of Lumen Level fields1408. The Lumen Level field1408includes the temperature in which a measurement was taken and a list of normalized light intensity measurements1410, one per color being measured in this system.

FIG. 15depicts an embodiment1500for handling the lumen level or light intensity by the system. Lumen level handling process428is triggered1508by either a scheduling event or by a system update of luminaire sensor information. In step1506the process checks for events. If an event is found to exist, it continues to step1508. Otherwise, the process goes into a waiting, or sleep mode1504and checks periodically for an event. The scheduling event1508can be based on the Lumen Level Scheduling DB1502, which is maintained according to user and system specific setups (for example: preferred lumen level at preferred times). Upon an event, the lumen level handling process will read the 3 databases—the Lumen Level Scheduling DB1502, the Luminaire and Driver DB416, and the Dimming & Testing Schedule DB524.

Specifically, based upon data provided from any one of databases1502,416or524, the system can conclude that the lumen level needs to be adjusted. At such time, the server106may instruct the gateway102to adjust the dimming control and thereby adjust the lumen level of the luminaire.

A change in lumen level in a room or area local to a luminaire can be a result of a dimming schedule or testing schedule event. For operations depicted inFIG. 15, the system is provided with knowledge about the luminaire based on manufacturing and time as part of the Luminaire and Driver DB416. This information includes, amongst other things, the lumen level at multiple specific dimming levels. When the system is being initialized, a baseline for light intensity and environment sensor readings is established at those specific dimming levels. The correlation between the known measured information received in the Luminaire and Driver DB416and the baseline sensor readings provides the information needed to maintain lumen levels. Where the system is not experiencing a controlled dimming or environment testing event, the lumen level handling process will continue to step1510in which it compares the current Luminaire and Driver DB416information with the lumen level scheduling information. When the sensor subsystem108or gateway102, for example, determines that the sensor readings are outside the lumen level range expected or scheduled, e.g., at a certain dimming level, there is a need to change the dimming level such that the required level is met. In step1512the system calculates adjustments when needed per luminaire in the environment of the luminaire that triggered the event. In step1514, if any change is necessary, the lumen level handling process428will trigger a dimming change request(s) by updating the Dimming & Testing Schedule DB524. A Dimming & Testing Schedule DB524is provided for each gateway102, depending on the type of gateway102, such that the gateway reads the database information, as depicted inFIG. 6, and schedules a change to the dimming and testing schedule, and potential changes to the dimming level of the luminaire according to the results of the dimming and testing.

Accordingly, the exemplary disclosed devices, systems, and methods provide for automated and dynamic setting, adjusting, and maintaining lumen level of a luminaire by controlling dimming of the luminaire, wherein a server such as a cloud server correlates an initial measured lumen level reading to an initial dimming level, and a gateway sends lumen level readings from upward looking color sensors to the cloud server106when the lumen level sensor readings are outside of lumen level sensor ranges expected by the system. In the exemplary disclosed embodiments, the expected ranges of lumen levels may be communicated, for example, from the server106to the sensor subsystem108or gateway102, and either system may determine whether a measured lumen level is outside of the expected range provided by the server106. The cloud server106compares the lumen level sensor readings received from gateway106to the initial (or a previous) correlation of the measured lumen level sensor reading to the initial dimming level to determine whether the dimming control of the luminaire must be adjusted to maintain a lumen level of the luminaire. In various aspects, the cloud server instructs the gateway to keep the lumen level of the luminaire constant over time. Alternatively, the cloud server can instruct the gateway to adjust the lumen level of the luminaire so as to keep the lumen level of the luminaire at user-set preferences, or in response to pre-scheduled changes such as changes in ambient background lighting over the course of a day.

Although the sensor subsystem108and the upward looking sensor has been described according to the exemplary embodiments as determining a lumen level for one or more luminaires, the upward looking sensor in the same or other embodiments may measure any number of features of the luminaire, including but not limited to the color content, color intensity, light intensity, etc., at multiple color channels.

The disclosed devices, systems, and methods, in various embodiments, configurations and aspects, includes components, methods, processes, systems and/or apparatuses substantially developed as depicted and described herein, including various embodiments, sub-combinations, and subsets thereof. The disclosed system, in various embodiments, configurations and aspects, includes providing devices and processes in the absence of items not depicted and/or described herein or in various embodiments, configurations, or aspects hereof, including in the absence of such items as may have been used in previous devices or processes, e.g., for improving performance, achieving ease and/or reducing cost of implementation.

The foregoing discussion of the disclosed embodiments has been presented for purposes of illustration and description. The foregoing is not intended to limit the disclosure to the form or forms disclosed herein. In the foregoing Detailed Description for example, various features of the disclosed system are grouped together in one or more embodiments, configurations, or aspects for the purpose of streamlining the disclosure. The features of the embodiments, configurations, or aspects of the disclosed systems may be combined in alternate embodiments, configurations, or aspects other than those discussed above. This method of disclosure is not to be interpreted as reflecting an intention that the disclosed system requires more features than are expressly recited in each claim. Rather, as the following claims reflect, claimed features may be less than all features of a single foregoing disclosed embodiment, configuration, or aspect. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of the disclosed systems and methods.

Moreover, the description of the disclosed system has included descriptions of one or more embodiments, configurations, or aspects, and certain variations and modifications, other variations, combinations, and modifications that are within the scope of the disclosed system and methods, as may be within the skill and knowledge of those in the art. Furthermore, the above disclosure is not limited by the exemplary embodiments and includes alternative embodiments, configurations, or aspects, to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangeable and/or equivalent structures, functions, ranges or steps are disclosed herein.