Devices, systems, and methods for maintaining luminaire color temperature levels in a gateway based system

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/521,817 filed Jun. 19, 2017. This application is a continuation-in-part of and claims priority to U.S. patent application Ser. No. 15/785,808 filed Oct. 17, 2017, which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/510,739 filed May 24, 2017 and is a continuation-in-part of and claims priority to U.S. patent application Ser. No. 15/424,868 filed Feb. 5, 2017, which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/445,669 filed Jan. 12, 2017 and is a continuation-in-part of and claims priority to U.S. patent application Ser. No. 15/360,879 filed Nov. 23, 2016, now U.S. Pat. No. 9,655,197, which claims the benefit of U.S. Provisional Patent Application Ser. No. 62/306,636 filed Mar. 11, 2016. This application also claims the benefit of U.S. Provisional Patent Application Ser. No. 62/420,908 filed Nov. 11, 2016. The disclosures of all of the applications listed above are incorporated herein by reference in their entireties.

FIELD OF THE DISCLOSURE

0002The disclosure relates generally to commissioning and maintaining lighting systems. More specifically, the disclosure is directed to monitoring and maintaining the color temperature of a luminaire or group of luminaires in a lighting system using dimming controls and predicting the useful life of luminaires based on color temperature degradation of the luminaire.

BACKGROUND OF THE DISCLOSURE

0003The lifetime of traditional light sources (incandescent, fluorescent, and high-intensity discharge lamps) is estimated through industry-standard lamp rating procedures. The number is determined by an operation that runs a large, statistically significant sample of lamps 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).

0004One reason why LED-based luminaires have gained popularity 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 becomes problematic—for example, 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 associated with the luminaire, associated systems, and the environment in which the luminaire is installed.

0005Digital intelligent lighting control systems can switch and dim individual luminaries in a light scene or space, such as an area within a building, which provides a great amount of flexibility, for example, setting appropriate LED output under particular conditions including the current LED lumen depreciation, to maintain desired levels of LED output. Such lighting control systems have user-friendly features for installation, programming, and operation. For example, lighting control systems can be integrated into a building management system as a subsystem of the central lighting controls.

0006A lighting control network generally includes one or more lighting devices; e.g., an electrical ballast including a luminaire, a light source such as an LED, and a dimmer, among other things. The dimmer must support specific interfaces for receiving control inputs for the luminaire/light source and dimming the light appropriately. Different lighting devices can support different control interfaces for dimming, e.g., to generate a particular color temperature as between different LED brands and/or powers.

0007The color temperature of a luminaire is the look and feel of the light produced by the luminaire. Color temperature is measured in degrees Kelvin (K) on a scale of 1000-10,000. Color temperature indicates, among other things, the color characteristic of lights coming out of luminaires located in an environment. In a typical commercial and/or residential environment, the luminaires' color temperatures fall between 2000K and 6500K. At the lower end of the scale, from 2000K to 3000K, the light produced is called “warm white” and ranges from orange to yellow-white in appearance. At the middle portion of the scale, from 3100K to 4500K, the light produced is called “cool white” or “bright white.” Luminaires within this range emit a more neutral white light and may even have a slightly blue tint. Light produced above 4500K brings us to “daylight” color temperature of light. Luminaires with color temperatures of 4500K and above will give off a blue-white light that mimics daylight. The color temperature of the luminaire corresponds to the lumen level of the luminaire.

0008Current 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.

0009For 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 color temperature 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.

0010At 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 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, these 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.

0011Further, current techniques for controlling a dimming level of luminaires in a networked lighting system may require multiple standard protocols to accommodate different types of luminaires. The implementations of the techniques are accordingly varied and the resultant dimming levels of luminaires cannot be correlated across groups. For example, the color temperature of each luminaire may be individually controlled, e.g., every luminaire may have a sensor and a dimming control that can be set to a specific color temperature, but when a group of different types of luminaires occupy the same space, such as a single room, controlling the overall dimming level to produce a correct overall color temperature in the room is difficult. This problem is exacerbated as individual LEDs of particular luminaires respectively degrade at varying rates over time.

0012Thus, devices, systems, and/or 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, color temperature, and/or degradation state of at least one luminaire. For purposes of this disclosure, “real time” means substantial concurrency. “Real time” does not include any particular timeframe or limitation.

0013Such devices, systems, and methods may also be capable of maintaining the color temperature levels of each luminaire regardless of dimming protocols, type of luminaire, or environmental characteristics associated with the luminaire. Devices, systems, and methods which allow any dimming protocol to be used in the same space and yet generate a specific color temperature for the space provide further flexibility in lighting control systems.

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

0015For purposes of this disclosure, “real time” means substantial concurrency and does not include any particular time frame or limitation.

0016For purposes of this disclosure, a “driver” is, for example and without limitation, a separate or integral device, system, mechanism, etc. for actuating, initiating, controlling, or communicating a command or operation as part of the exemplary disclosed devices, systems, and methods.

0017In view of the above, the disclosed devices, systems, and methods use lumen degradation, predictive life, dimming control and protocols, and environmental conditions of a luminaire, among other things, to dynamically generate, change, and/or maintain desired color temperatures for a luminaire, group of luminaires, or lighted space.

BRIEF DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

0018The disclosed embodiments are generally related to devices, systems, and methods that generate, change, and/or maintain appropriate color temperature levels of one or more lights. The lights may be Light Emitting Diode (LED)-based luminaires which are part of a smart illumination system. In an exemplary embodiment the system includes, among other things, a gateway device that is connected to an LED-based luminaire and a server, such as a cloud server, over wired and/or wireless communication channels. The disclosed devices, systems, and methods may be used locally at a luminaire and/or via connected networks, such as Internet of Things (IoT) networks in a building or other space.

0019For 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.

0020In one or more exemplary embodiments, the disclosed systems and methods provide a system for controlling color temperature of a luminaire, including: a dimming control configured to control the dimming level and/or dimming protocol of the luminaire; at least one sensor subsystem configured to take color intensity readings of the luminaire and transmit the intensity readings to the server, either directly or via the gateway, if the color intensity readings are outside of a range expected by the sensor subsystem; and, a cloud server configured to calculate a color temperature of the luminaire based at least in part on the color intensity of the luminaire and determine whether the current dimming level and/or dimming control protocol of the luminaire needs to be adjusted to generate a desired color temperature and, if so, instruct the gateway how to adjust at least one of the dimming level and dimming control protocol of the luminaire to generate a desired color temperature. The cloud server calculates the color temperature, in part, by correlating the current color intensity and dimming level of the luminaire to a previous and/or initial color intensity and dimming level, and associated color temperature, of the luminaire.

0021In various aspects, the cloud server can instruct the gateway to adjust the dimming control to adjust the color temperature of the luminaire so as to keep the color temperature of the luminaire constant over time or keep the color temperature of the luminaire at user-set preferences. Additionally, the cloud server can optionally instruct the gateway to adjust the dimming control to adjust the color temperature of the luminaire in response to pre-scheduled changes (which may include changes in ambient background lighting over the course of a day).

0022In one embodiment, the system will notify the user when a luminaire can no longer maintain user preferences. The system measures the color temperature and when color performance falls below a certain level, the user will be notified that specific luminaires must be replaced in order to maintain preferences. This embodiment in accordance with the disclosed system allows a user to change a device in the system without impacting the color temperature of the newly replaced device or space in which the device resides. The system will access information stored on cloud servers that will cause the new/modified luminaire introduced into the system to automatically adopt and adjust to previously defined user preferences.

0023In another aspect, the 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 color temperature change of the luminaire over time and/or a comparison of the current color temperature and dimming level of the luminaire to a correlation between a previous color temperature and dimming level. In the same or different embodiments, the systems and methods include a luminaire database that collects information related to a luminaire including at least one of fitting and dimming components and test data, sensor reading ranges, and sensor readings from a sensor subsystem including time, dimming level, and temperature of each reading, and a server predicts and generates luminaire degradation profiles over time based on the information in the luminaire database.

BRIEF DESCRIPTION OF THE FIGURES

0024A more particular description will be rendered by reference to specific embodiments thereof that are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments thereof and are not therefore to be considered to be limiting of its scope, exemplary embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

0025<figref idref="DRAWINGS">FIG. 1</figref> illustrates a high-level system diagram of the universal smart lighting gateway;

0026<figref idref="DRAWINGS">FIG. 2</figref> illustrates an embodiment of the universal smart lighting gateway box diagram;

0027<figref idref="DRAWINGS">FIG. 3</figref> illustrates an embodiment of the sensor connection to the luminaire;

0028<figref idref="DRAWINGS">FIG. 3B</figref> is graph showing power factor vs. power consumption, according to an aspect;

0029<figref idref="DRAWINGS">FIG. 3C</figref> is graph showing S curve, according to an aspect;

0030<figref idref="DRAWINGS">FIG. 3D</figref> is graph showing DALI® logarithmic curve, according to an aspect;

0031<figref idref="DRAWINGS">FIG. 3E</figref> is graph showing linear dimming curve, according to an aspect;

0032<figref idref="DRAWINGS">FIG. 3F</figref> is graph showing square curve, according to an aspect;

0033<figref idref="DRAWINGS">FIG. 3G</figref> is graph showing dead band vs. dimming value, according to an aspect;

0034<figref idref="DRAWINGS">FIG. 3H</figref> is graph showing measured vs. perceived brightness, according to an aspect;

0035<figref idref="DRAWINGS">FIG. 3I</figref> is graph showing log vs. linear dimming test, according to an aspect;

0036<figref idref="DRAWINGS">FIG. 3J</figref> is graph showing perceived brightness vs. power consumption, according to an aspect;

0037<figref idref="DRAWINGS">FIG. 4</figref> depicts an embodiment of the system procedural global event handling;

0038<figref idref="DRAWINGS">FIG. 5</figref> depicts an embodiment of the system handling of device setup stage;

0039<figref idref="DRAWINGS">FIG. 6</figref> depicts an embodiment of handling a gateway Standard Operational Mode;

0040<figref idref="DRAWINGS">FIG. 7</figref> depicts an embodiment of creating ‘Updates Message’;

0041<figref idref="DRAWINGS">FIG. 8</figref> depicts an embodiment of the cloud servers calculating specific luminaire half-life prediction information;

0042<figref idref="DRAWINGS">FIG. 8A</figref> depicts an exemplary light degradation graph;

0043<figref idref="DRAWINGS">FIG. 9</figref> depicts an embodiment of sensor interfaces data structures;

0044<figref idref="DRAWINGS">FIG. 10</figref> depicts an embodiment of message structure for messages delivered from the gateway to the cloud servers;

0045<figref idref="DRAWINGS">FIG. 11</figref> depicts an embodiment of message structure for message delivered from the cloud servers to the gateway;

0046<figref idref="DRAWINGS">FIG. 12</figref> depicts an embodiment of the Luminaire Database structure;

0047<figref idref="DRAWINGS">FIG. 13</figref> depicts an embodiment of the Events Database and the Message Status Database structures;

0048<figref idref="DRAWINGS">FIG. 14</figref> depicts an embodiment of the Luminaire Half-Life Prediction Database structure; and,

0049<figref idref="DRAWINGS">FIG. 15</figref> depicts an embodiment of handling the color temperature by the system.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

0050The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this disclosure, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean including but not limited to. To facilitate understanding, reference numerals have been used, where possible, to designate like elements common to the figures.

0051Various 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.

0052Reference will now be made in detail to various 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.

0053The phrases “at least one”, “one or more”, and “and/or” are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions “at least one of A, B and C”, “at least one of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B, or C” and “A, B, and/or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.

0054The term “a” or “an” entity refers to one or more of that entity. As such, the terms “a” (or “an”), “one or more” and “at least one” can be used interchangeably herein. It is also to be noted that the terms “comprising”, “including”, and “having” can be used interchangeably.

0055The terms “determine”, “calculate” and “compute,” and variations thereof, as used herein, are used interchangeably and include any type of methodology, process, mathematical operation or technique.

0056The 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.

0057The term “computer-readable medium” as used herein refers to any tangible storage and/or transmission medium that participates in storing and/or providing instructions to a processor for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, Non-Volatile Random Access Memory (NVRAM), or magnetic or optical disks. Volatile media includes dynamic memory, such as main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, magneto-optical medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, solid state medium like a memory card, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read. A digital file attachment to e-mail or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. When the computer-readable media is configured as a database, it is to be understood that the database may be any type of database, such as relational, hierarchical, object-oriented, and/or the like. Accordingly, the disclosure is considered to include a tangible storage medium or distribution medium and equivalents and/or successor media, in which the software implementations of the disclosure are stored.

0058<figref idref="DRAWINGS">FIG. 1</figref> shows an exemplary embodiment of a system <b>100</b> for maintaining color temperature of a luminaire. One or more components of the system <b>100</b> may be installed in an environment such as a building, room, hallway, or any other space in which lighting is desired. In the exemplary embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref>, a Universal Smart Lighting Gateway <b>102</b> (“gateway <b>102</b>”) is communicatively connected via wired or wireless communication channels to, among other things, a luminaire <b>112</b>. Luminaire <b>112</b> is a system that can be single or multiple luminaires connected with a single common interface to power lines <b>120</b>, <b>124</b> and dimming control lines <b>122</b>, <b>126</b>. In the exemplary embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref>, luminaire <b>112</b> includes associated LED <b>111</b>. There is a power meter <b>114</b> that is connected electrically between the gateway <b>102</b> and the luminaire <b>112</b> on the power lines <b>120</b>, <b>124</b>. The power meter <b>114</b> is connected to the gateway <b>102</b> via the power meter interface <b>132</b> and can measure and communicate the electrical power drawn by the luminaire in real time. <figref idref="DRAWINGS">FIGS. 2 and 9</figref> demonstrate the power meter <b>114</b> connections in more detail. There is a sensor subsystem <b>108</b> that is communicatively connected to the luminaire <b>112</b> on one side and to the gateway <b>102</b> on the other side. The connection <b>130</b> to the luminaire <b>112</b> may be physical or wireless and is not limited to a specific location. The location of the sensor subsystem <b>108</b> and/or associated sensors may be different for various types of sensors that need to be positioned. <figref idref="DRAWINGS">FIG. 3</figref> demonstrates one embodiment of sensor physical interface and connections including the sensor interface <b>128</b> to the gateway <b>102</b>.

0059With continuing reference to <figref idref="DRAWINGS">FIG. 1</figref>, cloud servers <b>106</b> are continuously receiving performance measurements for one or more luminaires from one or more gateways such as gateway <b>102</b>. In one embodiment the cloud servers <b>106</b> reciprocally provide every gateway <b>102</b> and/or sensor subsystem <b>108</b> with a table of reading directions that includes expected ranges of color intensity readings for particular luminaires at specific dimming levels, as explained further below. In the exemplary embodiment shown in <figref idref="DRAWINGS">FIG. 1</figref>, information may be exchanged between the servers <b>106</b> and the sensor subsystem <b>108</b> via gateway <b>102</b>. In the same or other embodiments, the sensor subsystem <b>108</b> and servers <b>106</b> may communicate directly by, for example, a wireless connection between the sensor subsystem <b>108</b> and network gateway <b>104</b> (discussed further below). The sensor subsystem <b>108</b> thereby determines whether a color intensity reading of the luminaire <b>112</b> is outside of the expected range and, if so, transmits the color intensity reading to the cloud server(s) <b>106</b> either directly or via the gateway <b>102</b>. Transmitting only color intensity readings that are outside of the expected range reduces the amount of information that needs to be transmitted over a gateway backhaul <b>118</b>, as shown in <figref idref="DRAWINGS">FIG. 1</figref>. In this way the cloud server applications can control the rate of information sent by the sensor subsystem <b>108</b>/gateway <b>102</b> and more accurately predict the luminaire <b>112</b>/LED <b>111</b> behavior. In the same or other embodiments, sensor readings and other information may be sent over the backhaul <b>118</b> to the cloud server <b>106</b> at random times. Such messages may include a time stamp of the subject sensor reading and current dimming level of the luminaire <b>112</b>.

0060The backhaul interface <b>118</b> to the gateway <b>102</b> can be a wired or wireless Local Area Network (LAN, WLAN), including possibly one or more of Mesh Bluetooth Low Energy (Mesh BLE), ZigBee, and/or Ethernet LAN. In one embodiment this interface is Mesh BLE. The gateway <b>102</b> is connected with a network gateway <b>104</b> which resides between the local networks to a wide area network (WAN) <b>116</b>, and via this WAN <b>116</b> to cloud computers/servers <b>106</b> for operational and management interfaces.

0061<figref idref="DRAWINGS">FIG. 2</figref> depicts an exemplary embodiment <b>200</b> of the Universal Smart Lighting Gateway <b>102</b>. <figref idref="DRAWINGS">FIG. 2</figref> illustrates a soft switch <b>202</b> to select between different electrical dimming interfaces. This soft switch <b>202</b> may be actively used in the search for the correct dimming protocol between the gateway <b>102</b> and the dimming luminaire <b>112</b> (not shown in this figure) to set desired dimming levels and generate desired color temperatures of the luminaire <b>112</b>. The protocol modules <b>228</b>, <b>230</b>, and <b>232</b> are the software implementation of the dimming interfaces that reside in the gateway <b>102</b>. In one embodiment the supported dimming protocol includes several sets of protocols 0V-10V, 1V-10V, pulse width modulation (PWM) 228 protocols over 0V-10V and/or 1V to 10V, a 24V DALI 230 protocol, and a 5V digital multiplex (DMX) 232 protocol. The protocols' algorithms may be implemented in the Micro Controller Unit <b>2</b> (MCU-<b>2</b>) <b>204</b>. According to an embodiment, the MCU-<b>2</b><b>204</b> is powered by the AC to DC 5V, 24V <b>220</b> via the power line connection <b>240</b>. MCU-<b>2</b><b>204</b> is also connected to a power meter <b>114</b> via MCU <b>1</b> and a Universal Asynchronous Receiver/Transmitter (UART) <b>224</b>. MCU-<b>2</b> may also be connected to a Relay <b>206</b> and/or a Wireless Interface Module (WIM) <b>210</b> via a Serial Peripheral Interface (SPI) bus <b>212</b>. In an embodiment, the MCU-<b>2</b><b>204</b> is also controlling the Relay <b>206</b> that is designed to be able to cut off the current to the luminaire <b>112</b> upon a decision by the MCU-<b>2</b><b>204</b>. The power cutoff can be used to disconnect power from the controlled luminaire subsystem (See <figref idref="DRAWINGS">FIG. 1</figref>). In an embodiment the Wireless Interface Module (WIM) <b>210</b> is implemented as Bluetooth Low Power (BLE) device using Mesh BLE protocol to connect with other devices as well having SPI bus <b>212</b> and Inter-Integrated Circuit two-wire serial interface bus (“TWSI”) <b>216</b>. The WIM <b>210</b> may be connected to a sensor subsystem that may include a Camera Interface System (CIS) <b>214</b>, which in the exemplary embodiments may include an environmental sensor and, for example, a Red-Green-Blue (RGB) and/or Yellow-Red-Green-Blue (YRGB) sensor combination device and other sensors. The CIS module <b>214</b> can be extended via Two-Wire Serial Interface (“TWSI”) bus <b>226</b> with other sensor modules. The CIS module <b>214</b> requires a clock, which is received via the AC Frequency to clock module interface <b>218</b>. The WIM <b>210</b> requires power, which may be received via the AC to DC 5V to 24V <b>220</b> via power interface line <b>240</b>. The AC Power 90V-240V <b>222</b> may be relayed to the MCU-<b>2</b><b>204</b> and from it to the soft switch <b>202</b> for power selection for the dimming protocol interfaces. The AC Power <b>222</b> is also relayed to the power meter <b>114</b> which measures all power delivered to the luminaire. The LNNL <b>234</b> depicts the physical electrical line connections.

0062<figref idref="DRAWINGS">FIG. 3</figref> depicts an embodiment <b>300</b> of the sensors—CIS module <b>308</b> or <b>310</b>—and the physical interface with the gateway <b>102</b> via Two-Wire Serial Interface (TWSI) connection using a 6-pin FPC cable and connector <b>306</b>. The exemplary CIS module (<b>308</b>, <b>310</b>) shown in <figref idref="DRAWINGS">FIG. 3</figref> is physically connected somewhere on the luminaire <b>112</b>. The exemplary CIS module <b>308</b> is a linear module that can be adopted to fit on devices that require a linear fitting, while the exemplary CIS module <b>310</b> is circular and is designed to fit circular luminaire modules. The CIS module(s) may take any required shape to fit with a particular luminaire.

0063In the exemplary embodiment shown in <figref idref="DRAWINGS">FIG. 3</figref>, CIS module <b>310</b> is physically connected to gateway <b>102</b> via connection <b>106</b>. The CIS module may also be in wireless communication with the gateway <b>102</b> without departing from the scope of the disclosure. Further, the disclosed embodiments do not limit the type of hardware/wire/bus interfaces between the gateway <b>102</b> and the sensor subsystem <b>108</b> or devices (CIS module <b>308</b>, <b>310</b>), 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.

0064In the exemplary disclosed embodiments, the CIS modules <b>308</b> and/or <b>310</b> may be provided with at least two or more sensors; one sensor is dedicated to environment sensing and one sensor which may be a color sensor configured to measure one or more aspects of a light source. The environment sensor is configured to face away or in a downward direction (i.e., “downward looking” or “down looking”) from the luminaire <b>112</b> and measure environmental conditions such as ambient light, temperature, humidity, motion, and/or the number of people passing through or present (“footfall”) in the environment in which the luminaire <b>112</b> is installed. The environment sensor 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. In the disclosed or other embodiments, the environment sensor may include three or more different sensors: a low-resolution image sensor, an ambient light sensor, and a temperature sensor (collectively, the “environment sensor”). In the exemplary disclosed embodiments, the environment sensor is configured to measure at least ambient light and temperature of the environment.

0065The color sensor faces the luminaire directly (i.e., the color sensor is “up looking” or “upward looking”) and measures, for example, color content and/or intensity of the light source. In the exemplary disclosed embodiments, the color sensor includes at least one Red Green Blue (RGB) sensor. In the same or other embodiments, the color sensor includes a Yellow Red Green Blue (YRGB) sensor and/or other color sensors consistent with this disclosure. The RGB sensor or combination of sensors can measure multiple color channels (e.g., Red, Green, Blue, and/or Yellow) as they directly face the luminaires. The RGB sensor may be used to measure both the color content of a light source and color intensity. In an exemplary embodiment, an RGB sensor measures and communicates to the server <b>106</b>, either directly or via gateway <b>102</b>, the color intensity of luminaire <b>112</b> relative to other luminaires, regardless of power or dimming level. This is due to the RGB sensor facing luminaire <b>112</b> directly and allows for an accurate maintenance of a color temperature 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 color intensity or color temperature because the RGB sensor directly provides the color intensity to the server <b>106</b>, which calculates color temperature based in part on the color intensity and determines whether and/or how color temperature will be maintained via the dimming control.

0066In 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 color 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 color intensity read by each individual sensor will be accurate. For example, red intensity is read respectively as x1 and y1 at each of two sensors at time t1 and, at t2, x2 and y2. In the example, x2/x1=y2/y1+w, where w&lt;&lt;1 and each sensor reads an accurate change in red intensity between t1 and 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 server <b>106</b>.

0067<figref idref="DRAWINGS">FIG. 3B</figref> shows 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. <figref idref="DRAWINGS">FIG. 3B</figref> also shows the associated power consumption at each dimming setting. In general, as shown in <figref idref="DRAWINGS">FIG. 3B</figref>, the power factor significantly decreases as the dimming level of the luminaire increases and the associated power consumption decreases. The representative graph shown in <figref idref="DRAWINGS">FIG. 3B</figref> indicates 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.

0068<figref idref="DRAWINGS">FIGS. 3C-3G</figref> depict 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 in <figref idref="DRAWINGS">FIGS. 3C-3G</figref> and explained further below. In <figref idref="DRAWINGS">FIGS. 3C-3G</figref>, 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).

0069<figref idref="DRAWINGS">FIG. 3C</figref> shows 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

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

0000<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mtable><mtr><mtd><mrow><mi>Y</mi><mo>=</mo><mfrac><mn>100</mn><mrow><mn>1</mn><mo>+</mo><msup><mi>e</mi><mrow><mrow><mo>-</mo><mn>0.1</mn></mrow><mo></mo><mrow><mo>(</mo><mrow><mi>x</mi><mo>-</mo><mn>50</mn></mrow><mo>)</mo></mrow></mrow></msup></mrow></mfrac></mrow></mtd><mtd><mrow><mo>(</mo><mrow><mi>eq</mi><mo>.</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>1</mn></mrow><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US2018098403A1_D0001.tif" />

0071where:

0072X=Dimming value (%)

0073<figref idref="DRAWINGS">FIG. 3D</figref> shows 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 in <figref idref="DRAWINGS">FIG. 3D</figref> will 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:

0000<maths id="MATH-US-00002" num="00002"><math overflow="scroll"><mtable><mtr><mtd><mrow><mi>Y</mi><mo>=</mo><msup><mn>10</mn><mrow><mo>(</mo><mfrac><mrow><mi>x</mi><mo>-</mo><mn>1</mn></mrow><mrow><mn>253</mn><mo>/</mo><mn>3</mn></mrow></mfrac><mo>)</mo></mrow></msup></mrow></mtd><mtd><mrow><mo>(</mo><mrow><mi>eq</mi><mo>.</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>2</mn></mrow><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US2018098403A1_D0002.tif" />

0000where:

0000<maths id="MATH-US-00003" num="00003"><math overflow="scroll"><mtable><mtr><mtd><mrow><mi>n</mi><mo>=</mo><mrow><mfrac><mi>X</mi><mn>100</mn></mfrac><mo>×</mo><mn>254</mn></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mrow><mi>eq</mi><mo>.</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>3</mn></mrow><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US2018098403A1_D0003.tif" />

0074X=Dimming Value (%)

0075<figref idref="DRAWINGS">FIG. 3E</figref> shows a representative linear dimming curve. A linear dimming curve as shown in <figref idref="DRAWINGS">FIG. 3E</figref> is calculated as follows:

0000<br /><i>Y=X</i>  (eq. 4)

0000where X=Dimming Value (%)

0076<figref idref="DRAWINGS">FIG. 3F</figref> shows a square curve dimming profile. A square curve as shown in <figref idref="DRAWINGS">FIG. 3F</figref> is calculated as follows:

0000<maths id="MATH-US-00004" num="00004"><math overflow="scroll"><mtable><mtr><mtd><mrow><mi>Y</mi><mo>=</mo><mfrac><msup><mi>X</mi><mn>2</mn></msup><mn>100</mn></mfrac></mrow></mtd><mtd><mrow><mo>(</mo><mrow><mi>eq</mi><mo>.</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>5</mn></mrow><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US2018098403A1_D0004.tif" />

0077where X=Dimming Value (%)

0078<figref idref="DRAWINGS">FIG. 3G</figref> shows 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 in <figref idref="DRAWINGS">FIG. 3G</figref>, 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 in <figref idref="DRAWINGS">FIG. 3G</figref>. 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.

0079Within 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 in <figref idref="DRAWINGS">FIGS. 3C-3G</figref>, 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.

0080There 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 in <figref idref="DRAWINGS">FIGS. 3C-3G</figref> are 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.

0081With reference now to <figref idref="DRAWINGS">FIG. 3H</figref>, 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 in <figref idref="DRAWINGS">FIG. 3H</figref>, is approximately:

0000<maths id="MATH-US-00005" num="00005"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><mi>PerceivedLight</mi><mo></mo><mstyle><mspace width="0.6em" height="0.6ex" /></mstyle><mo></mo><mrow><mo>(</mo><mi>%</mi><mo>)</mo></mrow></mrow><mo>=</mo><msqrt><mfrac><mrow><mi>MeasuredLight</mi><mo></mo><mstyle><mspace width="0.6em" height="0.6ex" /></mstyle><mo></mo><mrow><mo>(</mo><mi>%</mi><mo>)</mo></mrow></mrow><mn>100</mn></mfrac></msqrt></mrow></mtd><mtd><mrow><mo>(</mo><mrow><mi>Eq</mi><mo>.</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>6</mn></mrow><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US2018098403A1_D0005.tif" />

0082With reference now to <figref idref="DRAWINGS">FIG. 3I</figref>, 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 in <figref idref="DRAWINGS">FIG. 3I</figref>. 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:

0000<maths id="MATH-US-00006" num="00006"><math overflow="scroll"><mtable><mtr><mtd><mrow><mrow><mi>Light</mi><mo></mo><mstyle><mtext>/</mtext></mstyle><mo></mo><mi>PowerRatio</mi></mrow><mo>=</mo><mfrac><mi>NormalisedPerceivedBrightness</mi><mi>NormalisedPowerConsumption</mi></mfrac></mrow></mtd><mtd><mrow><mo>(</mo><mrow><mi>Eq</mi><mo>.</mo><mstyle><mspace width="0.8em" height="0.8ex" /></mstyle><mo></mo><mn>7</mn></mrow><mo>)</mo></mrow></mtd></mtr></mtable></math></maths><img file="US2018098403A1_D0006.tif" />

0000Table 1, below, summarizes the results of the light/power analysis at various dimming levels for each of the logarithmic and linear dimming curves.

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="77pt" align="center" /><colspec colname="2" colwidth="56pt" align="center" /><colspec colname="3" colwidth="84pt" align="center" /><thead><row><entry namest="1" nameend="3" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Linear</entry></row><row><entry /><entry>Log Light/Power</entry><entry>Light/Power</entry></row><row><entry>Dimming</entry><entry>Ratio</entry><entry>Ratio</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="77pt" align="char" char="." /><colspec colname="2" colwidth="56pt" align="char" char="." /><colspec colname="3" colwidth="84pt" align="char" char="." /><tbody valign="top"><row><entry>0</entry><entry>1.000</entry><entry>1.000</entry></row><row><entry>10</entry><entry>1.210</entry><entry>1.025</entry></row><row><entry>20</entry><entry>1.292</entry><entry>1.105</entry></row><row><entry>30</entry><entry>1.268</entry><entry>1.162</entry></row><row><entry>40</entry><entry>0.820</entry><entry>1.198</entry></row><row><entry>50</entry><entry>0.623</entry><entry>1.306</entry></row><row><entry>60</entry><entry>0.324</entry><entry>1.382</entry></row><row><entry>70</entry><entry>0.162</entry><entry>1.460</entry></row><row><entry>80</entry><entry>0.094</entry><entry>0.762</entry></row><row><entry>90</entry><entry>0.096</entry><entry>0.099</entry></row><row><entry>100</entry><entry>0.000</entry><entry>0.000</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0083Further analysis of the two representative dimming curves as shown in <figref idref="DRAWINGS">FIG. 3J</figref> shows 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.

0084In 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 meter <b>114</b> and 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 <b>100</b> 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.

0085The 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 in <figref idref="DRAWINGS">FIGS. 3I and 3J</figref>, 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 luminaires <b>112</b>/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 luminaires <b>112</b> can be controlled across the group and in view of any changes to associated parameters of any individual luminaire <b>112</b>.

0086Further, 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.

0087Applying 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.

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

0089<figref idref="DRAWINGS">FIG. 4</figref> depicts an exemplary embodiment <b>400</b> in which the system operates at a high level. The cloud server <b>106</b> is in a reactive mode, waiting for events. Most of the time the cloud server <b>106</b> is in a sleep mode while waiting. The cloud server <b>106</b> wakes up regularly to check if an event exists <b>404</b>. <figref idref="DRAWINGS">FIG. 4</figref> depicts three different types of events <b>408</b>, <b>412</b>, and <b>418</b>, which are pertinent to this disclosure. The first event <b>408</b> is “Device is initializing” which is handled by the “Handle device setup and discovery” <b>410</b>. The details for these interactions are described in <figref idref="DRAWINGS">FIG. 5</figref>. The second type of event occurs when a “Baseline message received” <b>412</b>. A Baseline Message may include, for example and without limitation, full sensor readings from sensor subsystem <b>108</b>, power level readings from power meter <b>114</b>, and current dimming state for the luminaire <b>112</b>. The handling of ‘Baseline Message’ type of messages is described in <figref idref="DRAWINGS">FIG. 6</figref> for the gateway <b>102</b>. Finally, a third type of event is associated with ‘Updates Message’ handling <b>420</b> for the received “Updated messages” <b>418</b> (see <figref idref="DRAWINGS">FIG. 7</figref>). 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. After handling incoming messages of any type, e.g., Baseline Messages or Updates Messages, the measurement updates or changes are recorded in the Luminaire and Driver Database (DB) <b>416</b>. The handling of device setup and discovery is also recorded in the Luminaire and Driver DB <b>416</b> as depicted in <figref idref="DRAWINGS">FIG. 6</figref>.

0090After the handling of Baseline <b>412</b> and Updates <b>418</b> messages, the system will try to predict the luminaire half-life, or end of life, or adjust its predictions <b>422</b>. At step <b>428</b>, the system lets the color temperature handling control process know that an event occurred which may have changed the color temperature for a specific luminaire. Step <b>428</b> may entail adjusting the dimming level to adjust the color temperature and is described in further detail in <figref idref="DRAWINGS">FIG. 15</figref>. Changes in the dimming schedule of any luminaire will have impacts on its half-life expectancy; therefore, over time and based on usage, the predictions will change and become more accurate to the specific point-in-time of the measurements.

0091At step <b>402</b> system operations initiates. At step <b>404</b>, system checks if there are events which need to be handled. If there are events which need to be handled by the system, operation goes to step <b>406</b>. If there are no events which need to be handled by the system, the operation goes to step <b>424</b> in which the system enters sleep mode.

0092<figref idref="DRAWINGS">FIG. 5</figref> depicts an embodiment <b>500</b> of the system handling of device setup and discovery operations. The flow of information as it appears in the two separated parts of the system is as follows:

0093The first event after turning on a gateway <b>102</b> will be a request for information (RFI) <b>516</b> from the gateway <b>102</b> to the cloud server <b>106</b>. This will be asking the cloud server <b>106</b> to provide minimal initialization information <b>518</b>, or if it is already familiar with the controlled luminaire by this gateway <b>102</b>, provide more information <b>518</b> based on this knowledge. The cloud server <b>106</b> will return an information (Information) message <b>518</b> to the gateway <b>102</b>. The gateway <b>102</b> will set the appropriate dimming protocol for the luminaire and send a ready (Ready) message <b>520</b> to the cloud server. The Ready message <b>520</b> includes identifying the luminaire, its dimming protocol, and sensor information as collected during the dimming protocol test/discovery <b>506</b> by the gateway <b>102</b>. At step <b>508</b>, after receiving the Ready messages <b>520</b>, the cloud servers <b>106</b> may respond with the ‘Sensor Setup info’ <b>522</b> including, e.g., dimming and sensor information associated with the setup of the sensors for baseline and for tune-up. The gateway <b>102</b> will set the luminaire to the pre-defined states and collect the readings of the sensors <b>510</b>. The information collected is sent to the cloud server as part of ‘Sensor Readings’ message <b>526</b>. The cloud servers <b>106</b> then send back final tune-up information and a schedule for dimming and measurements that need to be done on a regular basis (Sensor Future Reading Schedule) <b>528</b>. The cloud server will update the Luminaire and Driver DB <b>416</b> and continue to System Operations <b>402</b>. The gateway <b>102</b> is recording the scheduling information in the Dimming &amp; Testing Schedule Database <b>524</b> and continues to a Standard Operational Mode <b>530</b>.

0094In another aspect, the gateway <b>102</b> and sensor subsystem <b>108</b> can be controlled such that measurements are taken, for example and without limitation, only when environment measurements are in a certain range, as well as when the dimming level is in a certain range. Therefore, the dimming parameters, the environmental reading parameters, and the sensor parameters and reading setup can all be controlled from outside of the gateway <b>102</b> via cloud servers <b>106</b> which are connected to the gateway <b>102</b> and/or sensor subsystem <b>108</b>.

0095<figref idref="DRAWINGS">FIG. 6</figref> illustrates an embodiment <b>600</b> of the handling of the gateway Standard Operational Mode <b>530</b>. In an embodiment, the gateway <b>102</b> may spend most of its time in a sleep mode <b>602</b> while waiting for a scheduled dimming control or sensor reading to occur according the dimming and sensor reading schedule (from Dimming &amp; Testing Schedule DB <b>524</b>). If the scheduled action is a Schedule Test Triggered <b>604</b>, for example, the gateway <b>102</b> may, at a specific time, set a specific dimming level, and wait for the set of sensor readings <b>606</b>. If the scheduled action is “Sensor Event Triggered <b>608</b>”, the gateway <b>102</b> may conduct/set sensor readings for, for example, the RGB sensor readings and/or environment sensor readings, which may be present and need to be read and processed. According to an aspect of the exemplary embodiment, monitoring of the sensor events at <b>610</b> occurs in parallel (i.e., in the background) while the gateway <b>102</b> is in sleep mode.

0096In an exemplary embodiment, the gateway <b>102</b> does not process or handle tasks that are not scheduled. The gateway <b>102</b> will only process scheduled tasks and will remain in sleep mode <b>602</b> unless a scheduled dimming or sensor action exists. The scheduled tasks can be, for example and without limitation, setting a new dimming level <b>606</b> and waiting for sensor events (e.g., <b>412</b>, <b>418</b>) <b>610</b> and/or taking one or more sensor readings <b>608</b>. According to an aspect, after the initialization <b>408</b> of the gateway <b>102</b>, the gateway <b>102</b> receives a scheduling message <b>514</b> from the cloud servers <b>106</b>. At step <b>604</b>, for instance, the gateway <b>102</b> may set parameters to populate the Dimming and Testing Schedule DB <b>524</b>. According to an aspect, the Receive scheduling and parameters updates <b>622</b> process will update the Dimming and Testing Schedule DB <b>524</b> and may also refresh a sleep timer for the gateway <b>102</b> based on the dimming and testing schedule. When a scheduled test is triggered <b>604</b>, the gateway <b>102</b> sets the dimming to the requested light percentage/lumen intensity <b>606</b>, and at the monitoring sensor event step <b>610</b>, the sensor events database <b>612</b> is updated and the gateway <b>102</b> enters sleep mode <b>602</b> until the next scheduled dimming control or sensor reading action.

0097According to an aspect of an exemplary embodiment, a scheduled dimming control and/or sensor reading action includes at least one sensor reading that is completed by the system <b>100</b>. The system <b>100</b> may send sensor measurement requests to the sensors directly or via the gateway <b>102</b>. The requests can be, for example, to perform an action only when the temperature readings reach a specific level/range, the AMP reading reaches a specific range, and read color intensity of the light source multiple times.

0098With further reference to <figref idref="DRAWINGS">FIG. 4</figref>, when a sensor event occurs there can be multiple outcomes. In an embodiment, if the sensor reading is the last sensor reading required for a specific associated dimming level, the gateway <b>102</b> will decide whether the resulting measurements justify a new baseline message <b>614</b> or an updates message (<figref idref="DRAWINGS">FIG. 7</figref>). The gateway <b>102</b> may generate a new baseline message and send it to the cloud server (<b>106</b>) <b>616</b> if, for example, no baseline reading exists or the current baseline sensor readings are different from previous, corresponding baseline sensor readings by a set threshold. The gateway <b>102</b> may decide to generate and forward to the cloud server <b>106</b> an updates message if, for example, the current sensor readings indicate that aspects of the color content or intensity, associated color temperature, and/or environment have changed since the last sensor readings, as described further below with respect to <figref idref="DRAWINGS">FIG. 7</figref>. The gateway <b>102</b> may also update the dimming control and sensor reading schedule <b>616</b> in the Dimming &amp; Testing Schedule DB <b>524</b> to set the next dimming control or sensor reading action before entering sleep mode <b>602</b>. In an exemplary embodiment, the gateway <b>102</b> will enter sleep mode whenever it is waiting for a dimming control or sensor reading action, or other associated, scheduled task.

0099According to an aspect, before the gateway <b>102</b> enters sleep mode the current sensor readings and associated information, such as the time of the reading, are recorded in the Sensor Events DB <b>612</b> for future processing or reference. Further, in the exemplary embodiment shown in <figref idref="DRAWINGS">FIG. 6</figref>, the gateway <b>102</b> updates a Message Status DB <b>618</b> with information regarding any baseline or updates messages that were (or were not) generated and or sent to the cloud servers <b>106</b>, including, for example, the differences between the current baseline sensor readings and previous baseline sensor readings compared to the threshold for a new baseline message. On the other hand, when a new baseline message is not required, the gateway <b>102</b> goes to step <b>620</b> for the updates message process described with respect to <figref idref="DRAWINGS">FIG. 7</figref>.

0100<figref idref="DRAWINGS">FIG. 7</figref> illustrates an exemplary embodiment of a process <b>700</b> for Creating an ‘Updates Message’ <b>620</b>. According to an aspect, the Creating an Updates Message <b>620</b> depends on the accumulation of all prior updates messages recorded in the Message Status Database <b>618</b>. The gateway <b>102</b> can read the Message Status DB <b>618</b> to identify past baseline and updates messages <b>702</b> and read the Sensor Events Database <b>612</b> to identify previous sensor readings. The gateway <b>102</b> is further configured to receive the current dimming level of the luminaire <b>112</b> and current sensor readings from the sensor subsystem <b>108</b>. Thus, the gateway <b>102</b> can identify sensor readings that have changed <b>704</b> from previous sensor readings and generate an updates message <b>706</b> to include those readings only and send this message to the cloud server <b>106</b>. Once the updates message is sent, the Message Status DB <b>618</b> is updated for future analysis and the gateway <b>102</b> may enter sleep mode and wait for the next scheduled dimming control or sensor reading action in the Standard Operational Mode <b>530</b>.

0101At step <b>702</b>, the gateway <b>102</b> after receiving messages from Message Status DB <b>618</b> identifies the last baseline message that had been sent and the Updates messages that followed. At step <b>704</b>, after receiving information from the Sensor Events DB <b>612</b>, gateway <b>102</b> identifies which of the events have been triggered and what changes have taken place in the values for the appropriate sensors. At step <b>706</b>, the gateway <b>102</b> generates an Updates message, which includes the differences only between last sent baseline message and the accumulated updates message information and the current sensor readings <b>612</b>. At step <b>530</b>, the gateway <b>102</b> moves into standard operational mode <b>530</b>. At the same time, at step <b>706</b>, the gateway <b>102</b> updates the Message Status DB <b>618</b>.

0102<figref idref="DRAWINGS">FIG. 8</figref> depicts an exemplary embodiment <b>800</b> of cloud servers calculating specific luminaire half-life prediction information, as follows. In order to calculate luminaire degradation, color sensors provide color intensity and/or luminosity readings/measurements that are linearly correlated to a luminaire light intensity depreciation graph (<figref idref="DRAWINGS">FIG. 8A</figref>). 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 color 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, etc. The disclosed systems and methods allow the color 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.

0103When 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 DB <b>416</b> may be generated. The Luminaire and Driver DB <b>416</b> includes information that is specific to the fitting and dimming, as well as to the sensor reading ranges, etc., associated with the specific luminaire. The Luminaire and Driver DB <b>416</b> also includes information such as past sensor readings, associated times of reading, dimming level, temperatures, current readings, etc. Sensor readings such as color intensity can be normalized based on the original (initial) readings received upon installation and/or commissioning of the luminaire in the lighting system as in <figref idref="DRAWINGS">FIG. 5</figref>.

0104In 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”) calculator <b>806</b>, is taking data that was collected over time in the Luminaire and Driver DB <b>416</b> for 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 is 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 environment temperatures and luminaire dimming levels to extrapolate the place of the luminaire color 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 color temperature and dimming level can be determined, and this relationship can be updated over time as the color temperature (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 Database <b>810</b> for future use, and the next step is to wait for the next event as part of the System Operations <b>402</b> (<figref idref="DRAWINGS">FIG. 4</figref>).

0105The multiple sensor readings associated with color 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 in <figref idref="DRAWINGS">FIG. 5</figref>.

0106At step <b>802</b>, after receiving information from LM-80 Luminaire DB <b>812</b> and Luminaire and Driver DB <b>416</b>, the cloud server <b>106</b> reads the color intensity information for a specific luminaire at a specific power level and temperature. The Luminaire and Driver DB <b>416</b> includes information that is specific to the fitting and dimming, as well as to the sensor reading expected ranges, etc., associated with the specific luminaire. The Luminaire and Driver DB <b>416</b> also includes all past sensor readings, with associated times of reading, dimming levels, temperatures and current readings. All of this was accumulated, as depicted in previous <figref idref="DRAWINGS">FIGS. 4, 5, 6, and 7</figref>. The multiple sensor readings can be normalized by dividing the present reading by the initial reading received upon installation and/or commissioning of the luminaire in the lighting system as in <figref idref="DRAWINGS">FIG. 5</figref>.

0107At step <b>804</b>, the cloud server <b>106</b> decides if the collected accumulated information is sufficient to continue with calculations. If the response is ‘Yes’, then the operation moves to step <b>806</b>. If the response is ‘No’, then the operation moves to step <b>402</b>, which is the system operation's main loop.

0108At step <b>806</b>, the TM-28 luminaire equivalent of IES TM-21 calculator takes data that was collected over time in the Luminaire and Driver DB <b>416</b> for a test sample and plots this information after normalization into TM-28 which is the luminaire equivalent of IES TM-21 calculator <b>806</b>. This step allows for prediction of lumen maintenance over time.

0109At step <b>810</b> the information generated in <b>806</b> is stored in the Luminaire Half-life Prediction Database <b>810</b> for future use.

0110<figref idref="DRAWINGS">FIG. 9</figref> depicts an embodiment <b>900</b> of the sensors interface data structures. The sensor interfaces include the Sensor Global Configuration Registers Interface <b>902</b>, the Environment Sensor Configuration Registers Interface <b>904</b>, and the Color Sensor Configuration Registers Interface <b>906</b>. 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. In <figref idref="DRAWINGS">FIG. 9</figref> the 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 in <figref idref="DRAWINGS">FIG. 9</figref>.

0111The Sensor Global Configuration Registers Interface <b>902</b> includes a plurality of global configuration registers responsible for performing a plurality of activities. Available Sensors —[0x01] <b>908</b> shows which sensors are available for the particular device. The Available Sensors —[0x01] <b>908</b> 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] <b>910</b> shows which sensors have generated an interrupt. Sensors Alarm Interrupts—[0x03] <b>912</b> enables/disables interrupt from each available sensor whenever an alarm is generated. Power Management—[0x04] <b>914</b> controls power up/power down functions for the different sensors. Configure Management—[0x05] <b>916</b> stores register values in non-volatile memory. Hardware Register Access Address (HRAA)—[0x06] <b>918</b> holds the address for accessing the internal hardware registers of sensors. Hardware Register Access Data (HRAD)—[0x07] <b>920</b> holds the data to load/store in the address given in the register HRAA—[0x06] <b>918</b>. Direct Hardware Register Access RW—[0x08] <b>922</b>, if it holds a value “1”, then the data in the register HRAD—[0x07] <b>920</b> is written to the address in register HRAA—[0x06] <b>918</b>. If Direct Hardware Register Access RW—[0x08] <b>922</b> holds a value “0”, then the data pointed to by register HRAA—[0x06] <b>918</b> can be read in register HRAD—[0x07] <b>920</b>.

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

0113The Color Sensor Configuration Registers Interface <b>906</b> includes a plurality of color specific sensors. In one embodiment, the colors are Red, Green and Blue (RGB). RGB Conf. —[0x50] <b>946</b> controls both calibration configuration and reports when a sensor reading is available. RGB Red Cal.—[0x51] <b>948</b> displays calibration constant for red value from RGB sensor. RGB Green Cal.—[0x52] <b>950</b> displays calibration constant for green value from RGB sensor. RGB Blue Cal.—[0x53] <b>952</b> displays calibration constant for blue value from RGB sensor. Red Value MSB—[0x54] <b>954</b> displays MSB result of Red value from RGB sensor. Red Value LSB—[0x55] <b>956</b> displays LSB result of Red value from RGB sensor. Green Value MSB—[0x56] <b>958</b> displays MSB result of Green value from RGB sensor. Green Value LSB—[0x57] <b>960</b> displays LSB result of Green value from RGB sensor. Blue Value MSB—[0x58] <b>962</b> displays MSB result of Blue value from RGB sensor. Blue Value LSB—[0x59] <b>964</b> displays LSB result of Blue value from RGB sensor. Any of a plurality of colors can be used for color 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.

0114<figref idref="DRAWINGS">FIG. 10</figref> depicts an embodiment <b>1000</b> of message structure for messages delivered from the gateway <b>102</b> to the cloud servers <b>106</b>. In one embodiment the message <b>1002</b> going to the cloud server <b>106</b> is of a single structure. This structure includes Message type <b>1004</b>, the sender gateway unique identification (Source: gateway ID) <b>1006</b>, a unique Reference ID <b>1008</b> and the Message body <b>1010</b>. The Message type <b>1004</b> informs the receiver about the type of the message. The reference ID <b>1008</b> is an internal number used when there is a conversation between the cloud servers <b>106</b> and the gateway <b>102</b>. The message body <b>1010</b> can be a baseline message or an updates message and it is structured the same in both cases.

0115In one embodiment ‘Message types’ <b>1004</b> can be a ‘Request for Information’ (RFI) <b>516</b>, which is sent upon initialization of the luminaire. A ‘Ready’ message <b>520</b> is sent during initializations of the luminaire after discovering the dimming protocol and when the gateway <b>102</b> is ready for further instructions. Sensor readings message <b>526</b> is sent to the cloud servers <b>106</b> during the initialization period. The ‘Baseline’ <b>412</b> and the ‘Updates’ <b>418</b> message types are used when sending baseline or updates messages that are based on cloud servers <b>106</b> prior scheduled sensor readings taken and/or transmitted by the specific gateway <b>102</b>.

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

0117The Sensor reading <b>526</b> part of the message includes a ‘Sensor type’ <b>1020</b> field to indicate which sensor reading this is (TEMP, ALS, RGB, etc.), a ‘Time taken’ <b>1022</b> field to indicate when it was taken, and a ‘Vector of readings around the time taken’ <b>1024</b> which includes multiple readings centered around the ‘Time taken’ <b>1022</b> field. 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’ <b>1022</b> field value.

0118<figref idref="DRAWINGS">FIG. 11</figref> depicts an embodiment <b>1100</b> of message structure for message delivered from the cloud servers <b>106</b> to the gateway <b>102</b>, as follows. In one embodiment the structure of the message <b>1102</b> is constant. This structure includes Message type <b>1104</b>, a target gateway unique identification <b>1106</b>, a unique Reference ID <b>1108</b> and the Message body <b>1110</b>. The Message type <b>1104</b> lets the receiver know what kind of message it is. The reference ID <b>1108</b> is an internal number used when there is a conversation between the cloud servers <b>106</b> and the gateway <b>102</b>. The Message body <b>1110</b> is a Sensor Future Reading Schedule <b>528</b> (see <figref idref="DRAWINGS">FIG. 5</figref>) in the disclosed embodiment.

0119In one embodiment the Message types <b>1104</b> are ‘Information’ <b>518</b>, ‘Sensor Setup Info’ <b>522</b> and ‘Test Schedule’ <b>1112</b>. The ‘Information’ <b>518</b>, such as the ‘Sensor Setup Info’ <b>522</b> messages provides the gateway <b>102</b> with information about valid ranges for sensor readings at different dimming levels. The Message body <b>1110</b> is a Sensor Future Reading Schedule <b>528</b> that is a baseline for the gateway <b>102</b> in its internal measurement and initialization cycle. The gateway <b>102</b> will have a default setup, yet this message can update this default.

0120In one embodiment the Sensor Future Reading Schedule <b>528</b> includes an ‘Action’ <b>1120</b> field, which is the dimming level, the ‘Start’ <b>1122</b> field, which is the start time for the test, the ‘Wait’ <b>1124</b> field which is the duration to wait before any measurement commences, followed by a list of sensors that participate in the measurements <b>1126</b>. The list of sensors is given as a list of Sensor ranges per sensor <b>1126</b>.

0121In one embodiment, the Sensor range <b>1126</b> includes ‘Sensor Type’ <b>1156</b> field, which identifies the sensor, ‘Test Type’ <b>1158</b> field, which informs the gateway <b>102</b> how to run the test, and ‘Min Value’ <b>1160</b> and ‘Max Value’ <b>1162</b> fields, which provide the valid range for the sensor in this test. In one embodiment the ‘Test Type’ <b>1158</b> directs the gateway <b>102</b> in ways to handle different sensor values. When Test Type <b>1158</b> is ‘Read Only’ <b>1166</b> the value of the sensor is retrieved regardless of range. When Test Type <b>1158</b> is ‘Outside of Range’ <b>1168</b> the value of the sensor must be outside of the range to be retrieved. When Test Type <b>1158</b> is ‘Wait for in range’ <b>1170</b> the gateway <b>102</b> does not continue with other readings until the specific sensor is in given range. When Test Type <b>1158</b> is ‘Wait for outside range’ <b>1172</b> the gateway <b>102</b> will not continue to read sensor values until this sensor value is outside the given range.

0122<figref idref="DRAWINGS">FIG. 12</figref> depicts an embodiment <b>1200</b> of the Luminaire and Driver DB <b>416</b> structure. In one embodiment the Luminaire and Driver DB <b>416</b> includes three types of records for every connected luminaire in the system. The records are: Sensor Baseline Information <b>1202</b>, Sensor Reading Schedule <b>1212</b> and Sensor Reading Result Record <b>1228</b>. There is single Sensor Baseline Information <b>1202</b> and Sensor Reading Schedule <b>1212</b> record per luminaire. The Sensor Reading Result Record <b>1228</b> is numbered between 1 and N. This type of record is being added for every reading result and is being kept for as long as needed, e.g., N can be very large.

0123In one embodiment the Sensor Baseline Information <b>1202</b> includes sensor range information for all possible dimming levels that might be tested for this specific luminaire. Each dimming action field <b>1206</b> includes the minimal Wait time <b>1208</b>, which the gateway <b>102</b> must wait before taking sensor measurements, and a list of Sensor range fields <b>1210</b>, one per sensor that needs to be monitored. The Luminaire ID <b>1204</b> field is for identifying the luminaire that this record belongs to.

0124In one embodiment the Sensor Reading Schedule <b>1212</b> record is identical to the Sensor Future Reading Schedule <b>528</b> as described in <figref idref="DRAWINGS">FIG. 11</figref>, except for one additional field—the Luminaire ID <b>1204</b> field that is used to identify the luminaire to which the record corresponds.

0125In one embodiment the Sensor Reading Result Record <b>1228</b> is an accumulation of the Sensor Reading Message <b>1030</b> as described in <figref idref="DRAWINGS">FIG. 10</figref>, except for one additional field—the Luminaire ID <b>1204</b> field which is used to identify the luminaire that this record belongs to. In fact, every time the cloud server <b>106</b> receive a Sensor Reading Message <b>1030</b> that might be a Baseline message or an Updates message, the cloud server <b>106</b> will store this message as a Sensor Reading Result Record <b>1228</b> for the specific luminaire.

0126<figref idref="DRAWINGS">FIG. 13</figref> depicts an embodiment <b>1300</b> of the Events Database <b>612</b> and the Message Status Database <b>618</b> structures. In one embodiment, as disclosed in <figref idref="DRAWINGS">FIG. 6</figref>, the Message Status DB <b>618</b> is an accumulation of all sensor events associated with the reporting of scheduled test results. The Sensor Events DB <b>612</b> is 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 Database <b>618</b> contains two records. The first record is a Sensor Readings Message Status Previous View <b>1302</b>, and the second record is the Sensor Readings Message Status Current View/Current Events Status <b>1314</b>. When reading events are triggered, the appropriate fields in the Readings Message Status Current View/Current Events Status <b>1314</b> record 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 Status <b>1314</b> is copied into the Sensor Readings Message Status Previous View <b>1302</b>. When a Baseline message is being sent the entire Sensor Readings Message Status Previous View <b>1302</b> record is being sent as is. The detailed description of the Sensor Readings Message Status Previous View <b>1302</b> and the Readings Message Status Current View/Current Events Status <b>1314</b> can be found in <figref idref="DRAWINGS">FIG. 10</figref> under Baseline or Updates and Sensor Readings Message <b>1030</b>.

0127<figref idref="DRAWINGS">FIG. 14</figref> depicts an embodiment <b>1400</b> of the Luminaire Half-Life Prediction Database <b>810</b> structure. This Database is a log for all Normalized Color Intensity Measurements per luminaire in the system. Every Color Intensity Log <b>1402</b> record (one per luminaire) includes the Luminaire ID <b>1204</b> field to uniquely identify the luminaire that this record belongs to. The Color Intensity Log <b>1402</b> record is composed of N Normalized Color Intensity Measurement <b>1406</b> records one per Date/Time in which this measurement was received. In one embodiment, the Normalized Color Intensity Measurement <b>1406</b> record is composed of a list of Temperature fields <b>1408</b>. The Temperature field <b>1408</b> includes the environment temperature in which a measurement was taken and a list of normalized color intensity measurements <b>1410</b>, one per color being measured in this system.

0128<figref idref="DRAWINGS">FIG. 15</figref> depicts an embodiment <b>1500</b> for handling the color temperature by the system. Color temperature handling process <b>428</b> is triggered <b>1508</b> by either a scheduling event or by a system update of luminaire sensor information. In step <b>1506</b> the process checks for events. If an event is found to exist, it continues to step <b>1508</b>. Otherwise, the process goes into a short sleep mode <b>1504</b> and wakes up later to check for an event. The scheduling event <b>1508</b> can be based on the color temperature scheduling database <b>1502</b>, which is maintained according to user and system specific setups (for example: preferred color temperatures at preferred times). Upon an event, the color temperature handling process will read the 3 databases—the color temperature scheduling database <b>1502</b>, the Luminaire and Driver DB <b>416</b> and the Diming and testing schedule database <b>524</b>.

0129Specifically, based upon data provided from any one of databases <b>1502</b>, <b>416</b> or <b>524</b>, the system can conclude that the color temperature needs to be adjusted. At such time, the gateway <b>102</b> can control the dimming control to thereby adjust the color temperature of the luminaire.

0130A change in color temperature in a room or area local to a luminaire can be a result of a dimming schedule or testing schedule event. For example, an environmental change such as illumination due to a change in luminaire dimming level(s) in one location can trigger a color temperature change at a different location. The disclosed systems and methods can correlate control between sensors across an entire lighting system and compensate for such change because the color content/intensity of specific luminaires is measured directly using up looking color sensors. For operations depicted in <figref idref="DRAWINGS">FIG. 15</figref>, the system is provided with knowledge about the luminaire based on manufacturing and time as part of the Luminaire and Driver DB <b>416</b>. This information includes, amongst other things, the color temperature at multiple specific dimming levels. When the system is being initialized, a baseline for sensor readings is established at those specific dimming levels. The correlation between the known measured information received in the Luminaire and Driver DB <b>416</b> and the base line sensor readings provides the information needed to maintain color temperatures. In one embodiment where the system is performing a controlled change and testing for a specific luminaire, the handler will ignore the event and will not try to change/adjust the room color temperature. In cases where the system is not experiencing controlled dimming or environment testing event, the color temperature handling process will continue to step <b>1510</b> in which it compares the current Luminaire and Driver DB <b>416</b> information with the color temperature scheduling information.

0131In the exemplary embodiments, the color sensor(s) measure color intensity of the luminaire. When the color intensity is outside of a range expected by the sensor, the sensor provides the color intensity readings to the server either directly or via the gateway. The server uses the information to calculate an associated color temperature of the luminaire and determines whether there is a need to change the dimming level such that the required color temperature level is met. In step <b>1512</b> the system calculates adjustments when needed per luminaire in the environment of the luminaire that triggered the event. Controlling the environment color temperature by each individual luminaire is possible in part because the exemplary system takes direct light intensity readings at each luminaire and correlates the light intensity of each luminaire to a color temperature. The server converts and correlates light intensity readings to color temperature using a mathematical correlation between, for example, an amount of light in the room as measured by the environment (down looking) sensor; a correlation between light intensity and dimming level of the luminaire at the time of reading versus the light intensity, dimming level, and color temperature of the luminaire at previous readings and/or during installation or initialization of the lighting system; the power consumption of the luminaire; and, the luminaire type and manufacturer. The server uses the correlation of light intensity to color temperature for each luminaire in a particular environment, i.e., space, to determine an overall color temperature of the environment and a correlation between the overall color temperature and light intensity and dimming level of each luminaire. As a result, the system may control the color temperature in an environment by adjustments when needed per luminaire.

0132In step <b>1514</b>, if any change is necessary, the color temperature handling process <b>428</b> will trigger dimming change request by updating the dimming and testing schedule database <b>524</b>. The dimming and testing schedule database <b>524</b> impacts the operations of the gateway such that every gateway reads its database information, as depicted in <figref idref="DRAWINGS">FIG. 6</figref>, and schedules a change to the luminaire according with its current setup.

0133The 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.

0134The 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.

0135Moreover, 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. 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.