TW202204939A - Predictive modeling for tintable windows - Google Patents

Abstract

Disclosed herein are systems, apparatuses, methods, and non-transitory computer readable media related to controlling tint of tintable window(s) that include various predictive modules, and quality assurance related modules.

Description

Predictive Modeling for Shaderable Windows

priority application

16/013,770號的接續案，為2016年11月09日申請之美國專利申請案第15/347,677號的接續案，為2015年5月7日申請之標題為「用於可著色窗之控制方法（CONTROL METHOD FOR TINTABLE WINDOWS）」的國際專利申請案第PCT/US15/29675號的部分接續案，該國際專利申請案主張2014年5月9日申請且標題為「用於可著色窗之控制方法（CONTROL METHOD FOR TINTABLE WINDOWS）」之美國臨時專利申請案第61/991,375號的權益；美國專利申請案第15/347,677號亦為2013年2月21日申請且標題為「用於可著色窗之控制方法（CONTROL METHOD FOR TINTABLE WINDOWS）」之美國專利申請案第13/772,969號的部分接續案；以上各者中之每一者特此以全文引用之方式且出於所有目的而併入。This application claims the benefit of: US Provisional Patent Application No. 63/145,333, filed February 3, 2021, entitled "PREDICTIVE MODELING FOR TINTABLE WINDOWS"; U.S. Provisional Patent, entitled "VIRTUAL SKY SENSORS AND SUPERVISED CLASSIFICATION OF SENSOR RADIATION FOR WEATHER MODELING," filed on Feb. 12, 2020 Application Serial No. 62/975,677; U.S. Provisional Patent Application No. 63/075,569, filed September 08, 2020, entitled "PREDICTIVE MODELING FOR TINTABLE WINDOWS," which is A continuation-in-part of US Patent Application No. 16/949,493, filed on October 30, 2020, a continuation-in-part of US Patent Application No. 16/946,168, filed on June 08, 2020, on November 25, 2019 A continuation of US Patent Application No. 16/695,057 filed on March 24, 2017, a continuation of US Patent Application No. 15/514,480 filed on March 24, 2017, which is an international patent application filed on September 29, 2015 National Entry Phase of Case No. PCT/US15/52822, which claims the benefit of US Provisional Patent Application No. 62/057,104, filed on September 29, 2014; A continuation-in-part of 17/008,342, the No. 1 U.S. patent application filed on June 20, 2018

Continuation of US Patent Application Serial No. 15/347,677, filed on Nov. 09, 2016, and a continuation of U.S. Patent Application Serial No. 15/347,677, filed on May 7, 2015, entitled "Control Method for Tintable Windows" (CONTROL METHOD FOR TINTABLE WINDOWS)", a continuation-in-part of International Patent Application No. PCT/US15/29675, which asserts that it was filed on May 9, 2014 and is entitled "Control Method for Tintable Windows" (CONTROL METHOD FOR TINTABLE WINDOWS)" U.S. Provisional Patent Application No. 61/991,375; U.S. Patent Application No. 15/347,677 also filed on February 21, 2013 CONTROL METHOD FOR TINTABLE WINDOWS", a continuation-in-part of US Patent Application No. 13/772,969; each of the above is hereby incorporated by reference in its entirety and for all purposes.

Electrochromism is a phenomenon in which materials exhibit (eg, reversible) electrochemically mediated changes in optical properties when placed in different electronic states, eg, as a result of being subjected to changes in voltage and/or current. Optical properties can be color, transmittance, absorbance, and/or reflectance. One electrochromic material is tungsten oxide (WO ₃ ). Tungsten oxide is a cathodic electrochromic material in which a color transition (eg, transparent to blue) occurs by electrochemical reduction.

Electrochromic materials can be incorporated into windows, for example, for domestic, commercial, and/or other uses. The color, transmittance, absorbance and/or reflectivity of such windows can be altered by inducing changes in the electrochromic material. Electrochromic windows are windows that can be electronically darkened or brightened. A (eg, small) voltage applied to the electrochromic device of the window will darken the window; reversing the voltage will brighten the window. This capability allows control of the amount of light passing through the window, and presents an opportunity for electrochromic windows to be used comfortably in the enclosure in which they are placed and as an energy saving device.

Although electrochromism was discovered in the 1960s, despite many recent advances in electrochromic technology, equipment, computer-readable media, and related methods of making and/or using such electrochromic devices, electrochromic Color-changing devices and particularly electrochromic windows have not yet begun to realize their full commercial potential.

Aspects disclosed herein alleviate at least some of the above-mentioned disadvantages.

In one embodiment, the present invention includes a control system comprising: a tintable window; a window controller coupled to the tintable window; and one or more forecast modules coupled to the window controller, One or more of the forecast modules include control logic configured to process signals from at least one sensor and provide forecasts indicative of environmental conditions at future times and/or expected windows at future times of the tintable window one or more outputs of the tint, and wherein the window controller includes control logic configured to control the tintable window based at least in part on the one or more outputs. In one embodiment, the one or more forecasting modules comprise a neural network. In one embodiment, the neural network comprises an LSTM network. In one embodiment, the neural network comprises a DNN network. In one embodiment, the forecast of environmental conditions includes short-term environmental conditions and relatively longer-term environmental conditions. In one embodiment, one or more forecasting modules are configured to implement machine learning. In one embodiment, the at least one sensor includes a light sensor and/or an infrared sensor. In one embodiment, the environmental conditions include weather conditions. In one embodiment, the environmental conditions include the position of the sun. In one embodiment, the one or more outputs are based, at least in part, on a rolling mean of maximum light sensor values and/or a rolling median of minimum infrared sensor values. In one embodiment, the one or more forecasting modules are configured to calculate a center of gravity average from a time series of readings.

In one embodiment, the present invention includes a control system comprising: a plurality of tintable windows; one or more window controllers coupled to the plurality of tintable windows; at least one sensor configured to provide a first output representing one or more environmental conditions; and one or more neural networks coupled to the one or more window controllers, wherein the neural network includes being configured to process the first output and provide Control logic for a second output representing a forecast of future environmental conditions, and wherein the one or more window controllers include control logic configured to control hue states of the plurality of tintable windows based at least in part on the second output. In one embodiment, the future environmental conditions include weather conditions. In one embodiment, the neural network comprises a supervised neural network. In one embodiment, the neural network includes an LSTM neural network and/or a DNN neural network. In some embodiments, the neural network comprises a dense neural network. In some embodiments, artificial intelligence predictions (eg, sensor value predictions) are fed into modules C and/or D. In some embodiments, the neural network lacks LSTMs and/or DNNs. In some embodiments, a module (eg, using artificial intelligence) predicts (eg, a sensor) a sequence of values. In some embodiments, the module finds the mean, mean, or median of the sequence of values and designates the mean/mean/median as the predicted sensor value (eg, to be communicated as input to devices such as C and/or D module). In one embodiment, the at least one sensor includes at least one light sensor and at least one infrared sensor, and wherein the first output includes a rolling mean of maximum light sensor readings and a rolling minimum infrared sensor reading median. In one embodiment, the second output is based at least in part on a majority agreement between the LSTM neural network and the DNN neural network.

In one embodiment, the present invention includes a method of controlling at least one tintable window comprising the steps of: using one or more sensors to provide an output indicative of recent environmental conditions; coupling the output to control logic; using control logic to predict future environmental conditions; and control a tint of at least one tintable window based at least in part on the forecast of future environmental conditions using the control logic. In one embodiment, the one or more sensors include one or more light sensors and one or more infrared sensors. In one embodiment, the control logic includes at least one of an LSTM and a DNN neural network. In one embodiment, the output includes a rolling mean of maximum light sensor readings and a rolling median of minimum infrared sensor readings.

In one embodiment, the present invention includes a method of controlling a tintable window using site-specific and seasonally differentiated weather data, comprising: obtaining, at the site, environmental readings from at least one sensor over an N day period ; store the readings on a computer-readable medium; on the most recent day of the N days or on the second day of the most recent day of the N days, process the readings by control logic configured to provide indications from at least a first output of a distribution of possible future ranges of ambient readings from a sensor; and controlling a tint of the tintable window based at least in part on the first output. In one embodiment, the control logic includes an unsupervised classifier. In one embodiment, the present invention further comprises: using control logic to forecast environmental conditions for the location on the most recent day of the N days or the second day of the most recent day of the N days. In one embodiment, the control logic includes a neural network. In one embodiment, the control logic includes one or more forecast modules configured to process signals from at least one sensor and provide a desired window indicative of a tintable window in future time a second output of the tint, and wherein the method further includes controlling the tint of the tintable window based at least in part on the second output. In one embodiment, the one or more forecasting modules comprise a neural network. In one embodiment, the neural network comprises an LSTM network. In one embodiment, the neural network comprises a DNN network. In one embodiment, the second output is based at least in part on a majority agreement between the LSTM neural network and the DNN neural network.

In one embodiment, the present invention includes a building control system comprising: at least one sensor configured to obtain environmental readings: a memory for storing environmental readings; and control logic configured to state to process environmental readings and provide a first output representing a possible future range of environmental readings from at least one sensor, wherein the first output is used at least in part to control a system of the building. In one embodiment, the system includes at least one tintable window and at least one tintable window controller. In one embodiment, the control logic includes one or more neural networks configured to process recent environmental readings and provide a second output representing a forecast of future environmental conditions at a future time. In one embodiment, the at least one window controller is configured to control the tint state of the at least one tintable window based at least in part on the first or second output. In one embodiment, at least one sensor is located on a roof or wall of a building. In one embodiment, the stored environmental readings include readings taken over multiple days, and wherein the most recent environmental readings include readings taken on the same day. In one embodiment, readings taken on the same day include readings taken within a time window of approximately several minutes. In one embodiment, the time window is 5 minutes. In one embodiment, the second output includes at least one rule indicating a desired window tint for the at least one tintable window at a future time, and the at least one tintable window controller is used to control the at least one tintable window to achieve the desired window at a future time tone. In one embodiment, the second output is based at least in part on a majority agreement between the LSTM neural network and the DNN neural network. In one embodiment, the control logic includes an unsupervised classifier.

Another aspect relates to a control system comprising: a tintable window; a window controller in communication with the tintable window; and another controller or server in communication with the window controller and including one or more forecasts A module, wherein the one or more forecast modules include control logic configured to use readings from at least one sensor to determine one or more outputs, the one or more outputs including an indication of environmental conditions at a future time The tint level of the tintable window at a future time is predicted and/or, and wherein the window controller is configured to transition the tintable window based at least in part on the one or more outputs. In one example, the one or more forecasting modules include neural networks (eg, dense neural networks or along short-term memory (LSTM) networks).

Another aspect relates to a control system: a plurality of tintable windows; one or more window controllers configured to control the plurality of tintable windows; at least one sensor configured to provide a first an output; and one or more processors including at least one neural network and in communication with one or more window controllers, wherein the at least one neural network is configured to process the first output and provide a forecast including future environmental conditions and wherein the one or more window controllers are configured to control hue states of the plurality of tintable windows based at least in part on the second output.

Another aspect relates to a method of controlling at least one tintable window. The method includes the steps of: receiving output from one or more sensors; predicting future environmental conditions using control logic; and determining a hue of at least one tintable window based at least in part on the forecast of future environmental conditions.

Another aspect relates to a method of controlling a tintable window using site-specific and seasonally differentiated weather data, the method comprising: receiving environmental readings from at least one sensor at the site during N days; The readings are stored on a computer-readable medium on the most recent day in or on the second day after the most recent day in N; the readings are processed by control logic to determine a range representing a possible future range of environmental readings from at least one sensor. a first output of the distribution; and sending a hue instruction to transition the tintable window to a hue level determined based at least in part on the first output.

Another aspect relates to a building control system comprising: at least one sensor configured to obtain environmental readings: memory for storing environmental readings; and control logic stored on the memory and is configured to process environmental readings to determine a first output representing a possible future range of environmental readings from at least one sensor, wherein the first output is used at least in part to control a system of the building.

Another aspect relates to a control system for controlling tintable windows at a building. The control system includes one or more window controllers and a server or another controller configured to receive historical sensor readings associated with current or past weather conditions, the server or another controller having Control logic with at least one neural network configured to forecast future weather conditions based at least in part on historical sensor readings and to determine tone scheduling instructions based at least in part on future environmental conditions. The one or more window controllers are configured to control based at least in part on one of hue scheduling commands received from the server or another controller and hue scheduling commands received from the geometric model and the clear sky model The tint level of one or more tintable windows in a building.

Another aspect relates to a method of determining the tint state of one or more tintable windows. The method includes: (a) determining current or future external conditions affecting selection of hue states of one or more tintable windows; (b) selecting a first model from a suite of models, the first model determined to be currently or performs better than other models from the model suite under future external conditions, wherein the models in the model suite are trained to determine the hue state of one or more tintable windows under multiple sets of external conditions or to determine a machine learning model of the information of the hue states; and (c) executing the first model and using the output of the first model to determine the current or future hue state of the one or more tintable windows.

Another aspect relates to a method configured to determine the hue state of one or more tintable windows. The system includes a processor and memory configured to: (a) determine current or future external conditions affecting selection of hue states for one or more tintable windows; (b) select a first model from a suite of models , the first model is determined to perform better under current or future external conditions than other models from the model suite, wherein the models in the model suite are trained to determine that one or more shading windows are a machine learning model of hue states under a set of external conditions or information used to determine those hue states; and (c) executing a first model and using the output of the first model to determine the current or future of one or more tintable windows Hue status.

Another aspect relates to a method of generating a computing system for determining the hue state of one or more tintable windows. comprising: (a) clustering or classifying different types of external conditions based at least in part on historical radiation profiles or patterns; and (b) training a machine learning model for each of the different types of external conditions, wherein the machine The learning model is trained to determine the hue states of the one or more shadeable windows under a plurality of sets of external conditions, or information used to determine the hue states.

Another aspect relates to a method of identifying a subset of feature inputs for a machine learning model configured to determine the hue state of one or more tintable windows under a plurality of sets of external conditions, or using information to determine the state of these hues. The method includes: (a) performing a feature elimination process on the set of available feature inputs for the machine learning model, thereby removing one or more of the available feature inputs and generating a subset of the feature inputs; and (b) utilizing A subset of feature inputs initializes the machine learning model.

Another aspect relates to a method configured to identify a subset of feature inputs for a machine learning model configured to determine the hue of one or more tintable windows under a plurality of sets of external conditions state, or information used to determine the state of those hues. The system includes a processor and memory configured to: (a) perform a feature removal process on a set of available feature inputs for a machine learning model, thereby removing one or more of the available feature inputs and generating a subset of feature inputs; and (b) initializing a machine learning model using the subset of feature inputs. In another aspect, the present disclosure provides a system, apparatus (eg, controller) and/or non-transitory computer-readable medium (eg, software) implementing any of the methods disclosed herein.

In another aspect, an apparatus for controlling at least one setting (eg, level) of one or more devices at a site includes: one or more controllers having circuitry, the one or more The controller is configured to: (a) be operatively coupled to a sensor database configured to store sensor data communicated from the virtual sensors and from one or more data sources; and (b) using the sensor data retrieved from the sensor database to control or direct the settings of a plurality of devices at the control site.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules. In some embodiments, the setting includes a hue level, wherein the one or more controllers are configured to: use sensor data retrieved from a sensor database to determine or direct determination of the hue of the plurality of tintable windows level; and transitioning or directing transition of the plurality of tintable windows to the determined hue level. In some embodiments, the sensor database is configured to store sensor data communicated from virtual sensors. In some embodiments, the sensor data communicated from the virtual sensor includes test data. In some embodiments, the apparatus further includes a deep neural network (DNN). In some embodiments, the sensor data communicated from the virtual sensor to the sensor database is predicted by a deep neural network (DNN). In some embodiments, the sensor database is configured to store sensor data from virtual sensors and communicated from one or more data sources. In some embodiments, the one or more controllers include a hierarchical control system configured to transition one or more tintable windows.

In another aspect, a non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product being read by one or more processors Take the time to cause one or more processors to perform the operations of one or more of the controllers described above.

In some embodiments, one or more processors are operatively coupled to a sensor database configured to store from virtual sensors and/or from one or more data sources Transmitted sensor data. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a method for controlling at least one setting of one or more devices at a location that performs the operations of one or more of the controllers described above.

In another aspect, a non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product being read by one or more processors fetching time to cause one or more processors to perform one or more operations comprising: controlling or directing control of a plurality of disposed at the location based at least in part on sensor data retrieved from the sensor database A configuration of a device in which the one or more processors are operatively coupled to a sensor database configured to store data from virtual sensors and communicate from one or more data sources Sensor data.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules.

In another aspect, a method of controlling at least one setting of one or more devices at a location, the method comprising: based at least in part on a sensor database from a sensor database and a sensor retrieved from a virtual sensor data to control or instruct to control the settings of a plurality of devices located at the location.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules.

In another aspect, an apparatus for controlling the tint of at least one tintable window, comprising: one or more controllers comprising circuitry, the one or more controllers configured to: (a ) is operatively coupled to a sensor database configured to (I) store sensor data communicated from virtual sensors and (II) store from at least one physical sensor (b) use the sensor data communicated from the virtual sensor to determine or guide the determination of a first set of hue states for at least one tintable window at a location (eg, a facility), the first hue The set of states includes one or more first hue states; (c) using sensor data communicated from the at least one physical sensor to determine or direct determination of a second set of hue states for at least the tintable window at the location, the first and (d) based at least in part on (i) the first set of hue states, (ii) the second set of hue states, or (iii) the first set of hue states and the A set of two-tone states alters or directs altering the hue of at least one tintable window.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules. In some embodiments, the sensor data communicated from the virtual sensor includes test data. In some embodiments, the test data includes time and/or date stamps and sensor values. In some embodiments, the one or more controllers include one or more forecast modules configured to use sensor data to determine or direct determination of one or more outputs, the one or more outputs including (i ) forecasts of environmental conditions at future times and/or (ii) the hue levels of at least one tintable window at future times. In some embodiments, the one or more prediction modules comprise a neural network. In some embodiments, the neural network comprises a deep neural network (DNN). In some embodiments, the at least one physical sensor includes a light sensor and/or an infrared sensor. In some embodiments, the environmental conditions include weather conditions. In some embodiments, the one or more outputs include a rolling value of a maximum first reading and/or a rolling value of a minimum second sensor reading, wherein the rolling value of the maximum first reading includes an average of the maximum light sensor readings , median, or average, and wherein the rolling value of the minimum second sensor readings includes the mean, median, or average of the minimum infrared readings. In some embodiments, the one or more outputs include a rolling value of the maximum light sensor reading and/or a rolling value of the minimum infrared sensor reading, wherein the rolling value of the maximum light sensor reading includes the maximum light sensor reading The mean, median, or average of readings, and where the rolling value of the minimum infrared sensor readings includes the mean, median, or average of the minimum infrared readings. In some embodiments, the one or more forecasting modules are configured to calculate a center of gravity average from a time series of readings. In some embodiments, operations (b) and (c) are performed by the same controller of the at least one controller. In some embodiments, operations (b) and (c) are performed by different ones of the at least one controller.

In another aspect, a non-transitory computer-readable program product for controlling the hue of at least one tintable window, the non-transitory computer-readable program product when read by one or more processors causes one or more A plurality of processors perform the operations of one or more controllers (eg, at least one controller) described above.

In some embodiments, one or more processors are operatively coupled to a sensor database configured to (i) store sensor data communicated from virtual sensors and (ii) storing sensor data communicated from at least one physical sensor. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a method of controlling the tint of at least one tintable window that performs the operations of any one of the one or more controllers described above.

In another aspect, a non-transitory computer-readable program product for controlling the hue of at least one tintable window, the non-transitory computer-readable program product when read by one or more processors causes one or more A plurality of processors perform operations comprising: (a) using sensor data communicated from the virtual sensor to determine or direct determination of a first hue state of at least one tintable window at a location (eg, a facility) (b) using sensor data communicated from at least one physical sensor to determine or guide determination of at least a second tintable window at a location a set of hue states, the second set of hue states comprising one or more second hue states; and (c) based at least in part on (i) the first set of hue states, (ii) the second set of hue states, or (iii) the first set of hue states A set of hue states and a second set of hue states alter the hue of at least one tintable window.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules.

In another aspect, a method of controlling the hue of at least one tintable window, the method comprising: (a) using sensor data communicated from a virtual sensor to determine or direct determination of a location (eg, a facility) at a location (b) use sensor data communicated from at least one physical sensor to determine or guide determining a second set of hue states for at least the tintable window at the location, the second set of hue states comprising one or more second hue states; and (c) based at least in part on (i) the first set of hue states, (ii) ) a second set of hue states or (iii) a first set of hue states and a second set of hue states to alter the hue of at least one tintable window.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules.

In another aspect, an apparatus for controlling a state of at least one device, the apparatus including one or more controllers including circuitry, the one or more controllers configured to: (a) be operatively coupled to a sensor database configured to store sensor data communicated from the virtual sky sensor and stored from at least one physical sensor The sensor data, wherein the sensor data communicated from the virtual sky sensor includes test data; (b) use the test data to determine or guide the determination of the first set of control states of the at least one device; (c) use the test data from at least one sensor data communicated by a physical sensor to determine or direct determination of a second set of control states for at least one device; and (d) based at least in part on (i) the first set of control states, (ii) the second set of control states Aggregate or (iii) a first set of control states and a second hue state control to alter or direct altering the state of at least one device.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, the one or more controllers are configured to: (I) compare the first set of control states with the second set of control states; and (II) use or direct use of the first control based at least in part on the comparison One of the set of states and the second set of control states controls the at least one device. In some embodiments, at least one device includes at least one tintable window, wherein the first set of control states includes a first set of hue states, and wherein the second set of control states includes a second set of hue states. In some embodiments, (b) and (c) are performed by the same controller of the at least one controller. In some embodiments, (b) and (c) are performed by different ones of the at least one controller.

In another aspect, a non-transitory computer-readable program product for controlling a state of at least one device, the non-transitory computer-readable program product when read by one or more processors causes one or more The processor performs the operations of any of the one or more controllers described above.

In some embodiments, one or more processors are operatively coupled to a sensor database configured to (i) store sensor data communicated from virtual sensors and (ii) storing sensor data communicated from at least one physical sensor. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a method of controlling a state of at least one device that performs the operations of any one of the one or more controllers described above.

In another aspect, a non-transitory computer-readable program product for controlling a state of at least one device, the non-transitory computer-readable program product when read by one or more processors causes one or more The processor performs operations comprising: (a) determining or directing determination of a first set of control states for at least one device using test data included in sensor data communicated from the virtual sky sensor; (b) determining or directing determination of a second set of control states for the at least one device using sensor data communicated from the at least one physical sensor; and (c) based at least in part on (i) the first set of control states, (ii) the Two sets of control states or (iii) a first set of control states and a second hue state control to alter or direct altering the state of at least one device, wherein one or more processors are operatively coupled to a sensor database, the The sensor database is configured to (I) store sensor data communicated from the virtual sky sensor and (II) store sensor data communicated from at least one physical sensor.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules.

In another aspect, a method of controlling a state of at least one device, the method comprising: (a) using test data included in sensor data communicated from a virtual sky sensor to determine or direct the determination of at least one a first set of control states for the device; (b) using sensor data communicated from the at least one physical sensor to determine or direct determination of a second set of control states for the at least one device; and (c) based at least in part on (i ) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control to alter or direct altering the state of at least one device.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules. In some embodiments, (I) sensor data communicated from the virtual sky sensor and (II) sensor data communicated from at least one physical sensor are stored in a sensor database.

In another aspect, an apparatus for controlling a state of at least one device, the apparatus including one or more controllers including circuitry, the one or more controllers configured is (a) operatively coupled to a sensor database configured to (i) store sensor data communicated from the virtual sensor and (ii) store from at least one The sensor data communicated by the physical sensor, wherein the sensor data communicated from the virtual sensor includes the test data for the first test case and the second test case; (b) using the data for the first test case test data to determine or direct determination of a first set of control states for at least one device; (c) use the test data for a second test case to determine or direct determination of a second set of control states for at least one device; and (d) at least The state of the at least one device is altered or directed to be altered based in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules. In some embodiments, the one or more controllers are configured to: compare (i) the first set of control states with (ii) the second set of control states; and use or direct use of the first control based at least in part on the comparison One of the set of states and the second set of control states controls the at least one device. In some embodiments, at least one device includes at least one tintable window, wherein the first set of control states includes a first set of hue states, and wherein the second set of control states includes a second set of hue states. In some embodiments, (b) and (d) are performed by the same controller of the at least one controller. In some embodiments, (b) and (d) are performed by different ones of the at least one controller.

In another aspect, a non-transitory computer-readable program product for controlling a state of at least one device, the non-transitory computer-readable program product when read by one or more processors causes one or more The processor performs the operations of any of the one or more controllers described above.

In some embodiments, one or more processors are operatively coupled to a sensor database configured to (i) store sensor data communicated from virtual sensors and (ii) storing sensor data communicated from at least one physical sensor, wherein the sensor data communicated from the virtual sensor includes test data for the first test case and the second test case. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a method of controlling a state of at least one device that performs the operations of any one of the one or more controllers described above.

In another aspect, a non-transitory computer-readable program product for controlling a state of at least one device, the non-transitory computer-readable program product when read by one or more processors causes one or more The processor performs operations comprising: (b) using the test data for the first test case to determine or direct determination of a first set of control states for the at least one device; (c) using the tests for the second test case and (d) based at least in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and a second hue state control to alter or direct altering the state of at least one device, wherein the one or more processors are operatively coupled to a sensor database configured to (i) store Sensor data communicated from the virtual sensor and (ii) stored sensor data communicated from at least one physical sensor, wherein the sensor data communicated from the virtual sensor includes for the first test case and The test data of the second test case.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules.

In another aspect, a method of controlling a state of at least one device, the method comprising: (b) using test data for a first test case to determine or direct determination of a first set of control states of at least one device; ( c) use the test data for the second test case to determine or guide the determination of a second set of control states for the at least one device; and (d) based at least in part on (i) the first set of control states, (ii) the second control The set of states or (iii) the first set of control states and the second hue state control to alter or direct altering the state of at least one device.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules. In some embodiments, the sensor database is configured to (i) store sensor data communicated from virtual sensors and (ii) store sensor data communicated from at least one physical sensor. In some embodiments, the sensor data communicated from the virtual sensor includes test data for the first test case and the second test case.

In another aspect, an apparatus for controlling a state of at least one device comprising one or more controllers comprising circuitry, the one or more controllers: (a) configured to be operatively coupled to a sensor database configured to store test data communicated from the virtual sensor; and (b) comprising one or more forecast modules, The one or more forecasting modules are configured to use test data communicated from the virtual sensor to determine or facilitate determining (I) one or more outputs, the one or more outputs including the first Forecasting environmental conditions and/or (II) a first tint level for at least one tintable window at a future time.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules. In some embodiments, one or more forecast modules are configured to use sensor data from readings obtained by at least one physical sensor to determine one or more additional outputs. In some embodiments, the future time is a first future time, and wherein the one or more additional outputs include a second predicted environmental condition at the second future time and/or the at least one tintable window at the second future time Two-tone level. In some embodiments, the first future time and the second future time are different future times. In some embodiments, the first future time and the second future time are the same future time. In some embodiments, the virtual sensor is a virtual sky sensor configured to predict sensor data outside the facility at a future time for the facility in which the at least one tintable window is located. In some embodiments, the one or more prediction modules comprise a neural network. In some embodiments, the neural network comprises a deep neural network (DNN). In some embodiments, the one or more forecasting modules include logic that uses machine learning to determine the output. In some embodiments, the at least one sensor includes a light sensor and/or an infrared sensor. In some embodiments, the first forecasted environmental conditions and/or the second environmental conditions comprise weather conditions. In some embodiments, the one or more outputs include a rolling value of a maximum first reading and/or a rolling value of a minimum second sensor reading, wherein the rolling value of the maximum first reading includes an average of the maximum light sensor readings , median, or average, and wherein the rolling value of the minimum second sensor readings includes the mean, median, or average of the minimum infrared readings. In some embodiments, the one or more outputs include a rolling value of the maximum light sensor reading and/or a rolling value of the minimum infrared sensor reading, wherein the rolling value of the maximum light sensor reading includes the maximum light sensor reading The mean, median, or average of readings, and where the rolling value of the minimum infrared sensor readings includes the mean, median, or average of the minimum infrared readings. In some embodiments, the one or more forecasting modules are configured to calculate a center of gravity average from a time series of readings. In some embodiments, the one or more controllers are configured to control the environment of the enclosure in which the at least one tintable window is disposed.

In another aspect, a non-transitory computer-readable program product for controlling a state of at least one device, the non-transitory computer-readable program product when read by one or more processors causes one or more The processor performs the operations of any of the one or more controllers described above.

In some embodiments, the one or more processors are operatively coupled to a sensor database configured to store test data communicated from the virtual sensors. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a method of controlling a state of at least one device that performs the operations of any one of the one or more controllers described above.

In another aspect, a non-transitory computer-readable program product for controlling a state of at least one device, the non-transitory computer-readable program product when read by one or more processors causes one or more a processor performing one or more operations, the one or more processors configured to be operatively coupled to a sensor database configured to store data communicated from the virtual sensor test data; and the non-transitory computer-readable program product includes one or more forecast modules configured to use test data communicated from virtual sensors to determine or facilitate determination (I ) one or more outputs including a first predicted environmental condition at a future time and/or (II) a first hue level at a future time for at least one tintable window.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, future sensor data is based at least in part on machine learning modules.

In another aspect, a method of determining a hue state of one or more tintable windows, the method comprising: (a) by labeling sensor data from a radiation profile using external conditions from weather feed data generating training data for the plurality of external conditions; (b) using the training data generated for the plurality of external conditions to train at least one machine learning model for the plurality of external conditions, wherein the at least one machine learning model is trained to determine one or more the hue states of the tintable windows under a plurality of external conditions or the information used to determine the hue states; and (c) at least in part by using the determined hue states to alter the hue of the one or more tintable windows.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors. In some embodiments, the plurality of external conditions are weather conditions. In some embodiments, weather feeds are received from third parties. In some embodiments, the radiation profile is segmented according to a plurality of external conditions of different types received from weather feeds. In some embodiments, the sensor data in each segment is marked with one of a plurality of external conditions. In some embodiments, the plurality of external conditions include sunny conditions, partly cloudy conditions, foggy conditions, rainy conditions, hail conditions, stormy conditions, and/or smog conditions.

In another aspect, a non-transitory computer-readable program product for determining the hue state of one or more tintable windows, the non-transitory computer-readable program product when read by one or more processors One or more processors are caused to perform the operations of any of the methods described above.

In some embodiments, one or more processors are operatively coupled to one or more tintable windows. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, an apparatus for determining a hue state of one or more tintable windows, at least one controller includes circuitry and is configured to perform the operations of any of the methods described above.

In some embodiments, at least two of the operations are performed by the same controller of the at least one controller. In some embodiments, at least two of the operations are performed by different ones of the at least one controller.

In another aspect, a non-transitory computer-readable program product for determining the hue state of one or more tintable windows, the non-transitory computer-readable program product when read by one or more processors causing one or more processors to perform operations comprising: (a) generating or instructing the generation of training data for a plurality of external conditions by labeling sensor data from the radiation profile with the external conditions from the weather feed data (b) using or directing the use of training data generated for a plurality of extrinsic conditions to train at least one machine learning model for a plurality of extrinsic conditions, wherein the at least one machine learning model is trained to determine that one or more shadeable windows are within a plurality of extrinsic conditions; and (c) at least in part by using the determined hue state to alter or direct altering the hue of one or more tintable windows.

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors.

In another aspect, an apparatus for determining a tint state of one or more tintable windows, the apparatus comprising at least one controller having circuitry configured to : (a) operatively coupled to one or more tintable windows; (b) generated or directed for a plurality of external conditions by tagging sensor data from the radiation profile with the external conditions from weather feed data generating training data; (c) using or instructing to utilize the training data generated for the plurality of extrinsic conditions to train at least one machine learning model for the plurality of extrinsic conditions, wherein the at least one machine learning model is trained to determine one or more colorable the hue state of a window under a plurality of external conditions or the information used to determine such hue state; and (c) at least in part by using the determined hue state to alter or direct altering the hue of one or more tintable windows .

In some embodiments, virtual sensors are configured to predict future sensor data. In some embodiments, future sensor data is based at least in part on readings from one or more physical sensors.

In another aspect, an apparatus for controlling at least one setting of one or more devices at a site includes one or more controllers having circuitry configured to: (a) operatively coupled to a virtual sensor that predicts at a first time the predicted sensor data of the physical sensor at a second time; (b) operatively coupled to the physical a sensor that measures real sensor data at a second time; (c) compares or directs comparison of predicted sensor data to real sensor data to produce a result; and (d) at least partially altering or directing altering one or more operations of the virtual sensor based on the results to produce an altered virtual sensor; and (e) controlling or directing control of one or more of the virtual sensors based at least in part on the altered virtual sensor At least one setting of the device.

In some embodiments, wherein the predicted sensor data is based at least in part on a machine learning module. In some embodiments, the one or more controllers are configured to use or direct the use of the results to monitor, within a time window, a comparison between: (i) a continuous prediction sense that is continuously predicted after the second time and (ii) continuous ground truth sensor data acquired continuously after the second time to produce continuous results. In some embodiments, the modification of one or more operations of the virtual sensor is based at least in part on the length of the time window. In some embodiments, the one or more controllers are configured to send or direct the sending of a notification based at least in part on the results. In some embodiments, at least one controller is configured to utilize or direct the utilization of data from virtual sensors and physical sensors for controlling at least one setting of one or more devices at a location. In some embodiments, one or more controllers utilize a network. In some embodiments, one or more devices include tintable windows. In some embodiments, the one or more devices include a building management system. In some embodiments, one or more controllers are configured to control the environment of the site. In some embodiments, virtual sensors utilize machine learning to predict sensor profiles. In some embodiments, at least two of (a) to (e) are performed by the same one of the at least one controllers. In some embodiments, at least two of (a) to (e) are performed by different ones of the at least one controller.

In another aspect, a non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product being read by one or more processors The one or more processors are timed to perform the operations of any one of the one or more controllers described above.

In some embodiments, the one or more processors are operatively coupled to a virtual sensor that predicts the predicted sensor data of the physical sensor at a second time at a first time. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product being read by one or more processors The timing causes one or more processors to perform operations comprising: (a) comparing or directing a comparison of predicted sensor data with real sensor data to produce a result, wherein the predicted sensor data is generated by virtual The sensor is generated at a first time, wherein the predicted sensor data is data of the physical sensor at a second time after the first time, and wherein the real sensor is produced by the physical sensor at a second amount of time and (b) altering or directing altering one or more operations of the virtual sensor to produce an altered virtual sensor based at least in part on the results; and (c) based at least in part on the altered virtual sensor Controls or directs control of at least one setting of one or more devices, wherein one or more processors are operatively coupled to the virtual sensor and the physical sensor. In some embodiments, the predicted sensor data is based at least in part on a machine learning module.

In another aspect, a method of controlling at least one setting of one or more devices at a location includes: (a) predicting predicted sensor data at a first time by using a virtual sensor; (b) measuring real sensor data at a second time using the physical sensor; (c) comparing the predicted sensor data with the real sensor data to generate a result; (d) altering the virtual sensing based at least in part on the result and (e) controlling at least one setting of one or more devices based at least in part on the modified virtual sensor. In some embodiments, the predicted sensor data is based at least in part on a machine learning module.

In another aspect, a non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product being executed by one or more processors The read causes one or more processors to perform the operations of any of the methods described above.

In some embodiments, one or more processors are operatively coupled to the physical sensor. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a method of determining the gain of sunlight and/or glare protection in a facility, the method comprising: (a) using measured sensor data of one or more physical sensors to a logic to generate a first instruction that transforms the hue of at least one tintable window disposed in the facility; (b) use the virtual sensor data of one or more virtual sensors to use the second logic generating a second instruction that shifts the hue of the tintable window; and (c) comparing the first instruction with the second instruction to determine any gain in daylight and/or glare protection in the facility.

In some embodiments, the virtual sensor data includes predicted future sensor data. In some embodiments, the predicted future sensor data is based, at least in part, on data from one or more physical sensors. In some embodiments, the predicted future sensor data is based at least in part on a machine learning module. In some embodiments, the first instruction carries a first timestamp, and wherein the second instruction carries a second timestamp, and wherein comparing the first instruction to the second instruction includes comparing the first timestamp to the second timestamp. In some embodiments, the one or more physical sensors include light sensors and/or infrared sensors. In some embodiments, the method further includes distinguishing between tinting the at least one tintable window to a darker hue and tinting the at least one tintable window to a lighter hue. In some embodiments, the method further includes applying one or more filtering operations to the measured sensor data and/or virtual sensor data. In some embodiments, the one or more filtering operations include boxcar filtering.

In another aspect, a non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product being executed by one or more processors The read causes one or more processors to perform the operations of any of the methods described above.

In some embodiments, one or more processors are operatively coupled to one or more physical sensors. In some embodiments, at least two of the operations are performed by the same one of the one or more processors. In some embodiments, at least two of the operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, an apparatus for determining the gain of sunlight and/or glare protection in a facility, the apparatus comprising at least one controller comprising circuitry, the at least one controller being configured to: (a) be operatively coupled to at least one physical sensor, at least one shadeable window, and at least one virtual sensor; (b) receive or direct reception of the measured sensing of the at least one physical sensor (c) using or directing the use of the measured sensor data to generate, according to first logic, a first instruction to shift the hue of at least one tintable window disposed in the facility; (d) receiving or instructing to receive virtual sensor data for at least one virtual sensor; (e) using or instructing the use of the virtual sensor data to generate second instructions using second logic to shift the hue of the tintable window; and (f) The first command and the second command are compared or directed to determine any gain in daylight and/or glare protection in the facility.

In some embodiments, the virtual sensor data includes predicted future sensor data. In some embodiments, the predicted future sensor data is based, at least in part, on data from one or more physical sensors. In some embodiments, the predicted future sensor data is based at least in part on a machine learning module. In some embodiments, the first instruction carries a first timestamp, and wherein the second instruction carries a second timestamp, and wherein the at least one controller is configured to perform at least in part by comparing the first timestamp with the second timestamp. Two timestamps to compare or direct the comparison of the first instruction with the second instruction. In some embodiments, the one or more physical sensors include light sensors and/or infrared sensors. In some embodiments, the at least one controller is configured to differentiate or direct a distinction between tinting the at least one tintable window to a darker hue and tinting the at least one tintable window to a lighter hue. In some embodiments, at least one controller is configured to apply or direct the application of one or more filtering operations to the measured sensor data and/or virtual sensor data. In some embodiments, the one or more filtering operations include square wave filtering. In some embodiments, at least two of (a) to (f) are performed by the same controller of the at least one controller. In some embodiments, at least two of (a) to (f) are performed by different ones of the at least one controller.

In another aspect, a non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product being executed by one or more processors The read causes one or more processors to perform one or more operations of any of the at least one controller described above.

In some embodiments, one or more processors are operatively coupled to one or more physical sensors. In some embodiments, at least two of the one or more operations are performed by the same one of the one or more processors. In some embodiments, at least two of the one or more operations are performed by different ones of the one or more processors. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. In some embodiments, the non-transitory computer-readable program product comprises a non-transitory computer-readable medium.

In another aspect, a non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product being executed by one or more processors When read causes one or more processors to perform one or more operations comprising: (a) receiving or directing receipt of measured sensor data for at least one physical sensor; (b) using or directing using the measured sensor data to generate, according to first logic, a first instruction to shift the hue of at least one tintable window disposed in the facility; (c) receiving or directing the receipt of at least one virtual sense (d) using or directing the use of the virtual sensor data to generate a second instruction that shifts the hue of the tintable window using the second logic; and (e) comparing or directing the comparison of the first instruction with the second instruction Two instructions to determine any gain in daylight and/or glare protection in the facility, wherein one or more processors are operatively coupled to at least one physical sensor, at least one tintable window, and at least one virtual sensor. In some embodiments, the virtual sensor data includes predicted future sensor data. In some embodiments, the predicted future sensor data is based, at least in part, on data from one or more physical sensors. In some embodiments, the predicted future sensor data is based at least in part on a machine learning module.

In another aspect, a method of controlling at least one level of one or more devices at a location, the method comprising: (a) receiving or directing receipt of measured sensor data for at least one physical sensor (b) using or directing the use of the measured sensor data to generate, according to first logic, a first instruction to shift the hue of at least one tintable window disposed in the facility; (c) receiving or instructing to receive virtual sensor data for at least one virtual sensor; (d) using or instructing the use of the virtual sensor data to generate a second instruction using second logic to shift the hue of the tintable window; and (e) comparing or The instructions compare the first command with the second command to determine any gain in daylight and/or glare protection in the facility. In some embodiments, the virtual sensor data includes predicted future sensor data. In some embodiments, the predicted future sensor data is based, at least in part, on data from one or more physical sensors. In some embodiments, the predicted future sensor data is based at least in part on a machine learning module.

In another aspect, the present disclosure provides a system, apparatus (eg, controller) and/or non-transitory computer-readable medium (eg, software) implementing any of the methods disclosed herein.

In another aspect, the present disclosure provides methods of using any of the systems, computer-readable media, and/or devices disclosed herein, eg, for their intended purposes.

In another aspect, an apparatus includes at least one controller programmed to direct means for implementing (eg, performing) any of the methods disclosed herein, the at least one controller being programmed to direct a mechanism for implementing (eg, performing) any of the methods disclosed herein. configured to be operatively coupled to the mechanism. In some embodiments, at least two operations (eg, of the method) are directed/performed by the same controller. In some embodiments, at least two operations are directed/performed by different controllers.

In another aspect, an apparatus includes at least one controller configured (eg, programmed) to implement (eg, perform) any of the methods disclosed herein. At least one controller can implement any of the methods disclosed herein. In some embodiments, at least two operations (eg, of the method) are directed/performed by the same controller. In some embodiments, at least two operations are directed/performed by different controllers.

In another aspect, a system includes at least one controller programmed to direct operation of at least one other device (or component thereof) and the device (or component thereof), wherein the at least one A controller is operatively coupled to the device (or components thereof). The apparatus (or components thereof) may include any apparatus (or components thereof) disclosed herein. At least one controller can be configured to direct any of the devices (or components thereof) disclosed herein. At least one controller can be configured to be operatively coupled to any of the devices (or components thereof) disclosed herein. In some embodiments, at least two operations (eg, among the devices) are directed by the same controller. In some embodiments, at least two operations are directed by different controllers.

In another aspect, a computer software product includes a non-transitory computer-readable medium storing program instructions that, when read by at least one processor (eg, a computer), cause at least one processor to direct the instructions herein The disclosed mechanism implements (eg, performs) any of the methods disclosed herein, wherein at least one processor is configured to be operatively coupled to the mechanism. The mechanism may include any device (or any component thereof) disclosed herein. In some embodiments, at least two operations (eg, among devices) are directed/performed by the same processor. In some embodiments, at least two operations are directed/performed by different processors.

In another aspect, the present disclosure provides a non-transitory computer-readable medium comprising machine-executable code that, when executed by one or more processors, implements any of the methods disclosed herein. a way. In some embodiments, at least two operations (eg, of a method) are directed/performed by the same processor. In some embodiments, at least two operations are directed/performed by different processors.

In another aspect, the present disclosure provides a non-transitory computer-readable medium comprising machine-executable code that, when executed by one or more processors, executes control of a controller (eg, as disclosed herein). In some embodiments, at least two operations (eg, among the controllers) are directed/performed by the same processor. In some embodiments, at least two operations are directed/performed by different processors.

In another aspect, the present disclosure provides a computer system including one or more computer processors and a non-transitory computer-readable medium coupled thereto. The non-transitory computer-readable medium includes machine-executable code that, when executed by one or more processors, implements any of the methods disclosed herein and/or exercises the controls disclosed herein device guidance.

The contents of this Summary section are provided as a simplified introduction to the disclosure and are not intended to limit the scope of any invention disclosed herein or the scope of the appended claims.

Additional aspects and advantages of the present invention will become apparent to those skilled in the art from the following description, in which only illustrative embodiments of the present disclosure are shown and described. As will be realized, the present disclosure is capable of other and different embodiments, and its several details are capable of modification in various obvious respects, all without departing from the present disclosure. Accordingly, the drawings and descriptions are to be regarded as illustrative and not restrictive in nature.

These and other features and embodiments are described in more detail below with reference to the drawings. incorporated by reference

All publications, patents and patent applications mentioned in this specification are incorporated herein by reference to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be by reference way incorporated into the general.

While various embodiments of the invention have been shown and described herein, it will be apparent to those skilled in the art that these embodiments are provided by way of example only. Numerous changes, changes, and substitutions can occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be used.

Terms such as "a/an" and "the" are not intended to refer to only the singular entity, but rather include the general class of specific instances that can be used for description. The terminology herein is used to describe specific embodiments of the invention, but their use does not delimit the invention.

The conjunction "and/or" in a phrase such as "including X, Y, and/or Z" is meant to include any combination or plural of X, Y, and Z. For example, this phrase is intended to include X. For example, this phrase is intended to include Y. For example, this phrase is intended to include Z. For example, this phrase is intended to include X and Y. For example, this phrase is intended to include X and Z. For example, this phrase is intended to include Y and Z. For example, this phrase is intended to include multiple X's. For example, this phrase is intended to include plural Ys. For example, this phrase is intended to include multiple Z's. For example, this phrase is intended to include plural X and plural Y. For example, this phrase is intended to include plural X and plural Z. For example, this phrase is intended to include Y's and Z's. For example, this phrase is intended to include a plurality of X and Y. For example, this phrase is intended to include a plurality of X and Z. For example, this phrase is intended to include a plurality of Y and Z. For example, this phrase is intended to include X and Y's. For example, this phrase is intended to include X and Z. For example, this phrase is intended to include Y and a plurality of Z. The conjunction "and/or" is intended to have the same effect as the phrase "X, Y, Z, or any combination or plural thereof." The conjunction "and/or" is intended to have the same effect as the phrase "one or more of X, Y, Z, or any combination thereof." The conjunction "and/or" is intended to have the same effect as the phrase "at least one X, Y, Z, or any combination thereof."

Unless otherwise specified, when referring to a range, the range is intended to be inclusive. For example, a range between value 1 and value 2 is intended to be inclusive and includes both value 1 and value 2. An inclusive range will span any value from about 1 to about 2. The terms "adjacent" or "adjacent to" as used herein include "adjacent", "adjacent", "contacting" and "proximity."

The terms "operatively coupled" or "operatively connected" refer to the coupling (eg, connection) of a first element (eg, mechanism) to a second element to allow intended operation of the second and/or first element . Coupling may include physical or non-physical coupling (eg, communicative coupling). Non-physical coupling may include signal-induced coupling (eg, wireless coupling). Coupling may include physical coupling (eg, a physical connection) or non-physical coupling (eg, via wireless communication). Operationally coupled may include communicative coupling.

An element (eg, mechanism) that is "configured to" perform a function includes structural features that cause the element to perform that function. Structural features may include electrical features, such as circuitry or circuit elements. Structural features may include circuitry (eg, including electrical or optical circuitry). The circuitry may include one or more wires. Optical circuitry may include at least one optical element (eg, a beam splitter, mirror, lens, and/or optical fiber). Structural features may include mechanical features. Mechanical features may include latches, springs, closures, hinges, chassis, supports, fasteners or cantilevers, and the like. Performing functions may include utilizing logical features. Logical features may include programmed instructions. The programmed instructions are executable by at least one processor. Programming instructions can be stored or encoded on a medium that can be accessed by one or more processors. Additionally, in the following description, the phrases "operable with," "adapted with," "configured with," "designed with," "programmed with," or "capable of" may be used interchangeably as appropriate use.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the presented embodiments. The disclosed embodiments may be practiced without one or more of these specific details. In other instances, well-known program operations have not been described in detail so as not to unnecessarily obscure the disclosed embodiments. Although the disclosed embodiments have been described in connection with specific embodiments, it should be understood that no limitation of the disclosed embodiments is intended. It should be understood that while certain disclosed embodiments focus on electrochromic windows, the aspects disclosed herein may be applied to other types of tintable windows. For example, tintable windows incorporating liquid crystal devices or suspended particle devices rather than electrochromic devices may be incorporated into any of the disclosed embodiments.

In various embodiments, the network infrastructure supports a control system for one or more windows such as tintable (eg, electrochromic) windows. The control system may include one or more controllers operatively coupled (eg, directly or indirectly) to the one or more windows. Although the disclosed embodiments describe tintable windows (also referred to herein as "optically switchable windows" or "smart windows"), such as electrochromic windows, the concepts disclosed herein may be applied to other types of Switchable optical devices, including liquid crystal devices, electrochromic devices, suspended particle devices (SPD), NanoChromics displays (NCD), organic electroluminescent displays (OELD), suspended particle devices (SPD), NanoChromics displays (NCD) or have Electromechanical Electroluminescent Displays (OELDs). The display element may be attached to a portion of the transparent body, such as a window. Tintable windows may be placed in (non-transitory) installations such as buildings, and/or in temporary vehicles such as automobiles, RVs, buses, trains, airplanes, helicopters, ships, or boats.

In order to acclimate the reader to the embodiments of the apparatus, systems, computer-readable media and/or methods disclosed herein, a brief discussion of electrochromic devices and window controllers is provided. This initial discussion is provided for context only, and the subsequently described embodiments of the system, window controller, and method are not limited to the specific features and manufacturing procedures of this initial discussion.

Certain disclosed embodiments provide network infrastructure in an enclosure (eg, a facility such as a building). The network infrastructure may be used for various purposes, such as for providing communication and/or power services. Communication services may include high bandwidth (eg, wireless and/or wireline) communication services. Communication services may be directed to occupants of the facility and/or users outside the facility (eg, a building). The network infrastructure may work in conjunction with or replace part of the infrastructure of one or more cellular operators. The network infrastructure may be provided in a facility that includes electrically switchable windows. Examples of components of a network infrastructure include high-speed backhaul. The network infrastructure may include at least one cable, switch, physical antenna, transceiver, sensor, transmitter, receiver, radio, processor and/or controller (which may include a processor). The network infrastructure is operably coupled to and/or includes a wireless network. Network infrastructure can include cabling. One or more sensors may be deployed (eg, installed) in the environment as part of and/or after installing the network. Communication services may be directed to occupants of the facility and/or users outside the facility (eg, a building). The network infrastructure may work in conjunction with or replace part of the infrastructure of one or more cellular operators. The network infrastructure may be provided in a facility that includes electrically switchable windows. Examples of components of a network infrastructure include high-speed backhaul. The network infrastructure may include at least one cable, switch, physical antenna, transceiver, sensor, transmitter, receiver, radio, processor and/or controller (which may include a processor). The network infrastructure is operably coupled to and/or includes a wireless network. Network infrastructure can include cabling. One or more sensors may be deployed (eg, installed) in the environment as part of and/or after installing the network. The network can be configured to provide power and/or communication. The network is operably coupled to one or more transmitters, transceivers, modems, routers and/or antennas. A network can consist of cables, including twisted pair, coaxial, or optical cables. The network may be configured for Internet and/or Ethernet communications. The network can be configured to support at least 3rd, 4th, or 5th generation cellular communications. The network can be configured to couple to one or more controllers. The network can be configured to couple to one or more devices, including: tintable windows, sensors, transmitters, antennas, and/or media display structures.

In various embodiments, the network infrastructure supports a control system for one or more windows such as tintable (eg, electrochromic) windows. The control system may include one or more controllers operatively coupled (eg, directly or indirectly) to the one or more windows. Although the disclosed embodiments describe tintable windows (also referred to herein as "optically switchable windows" or "smart windows"), such as electrochromic windows, the concepts disclosed herein may be applied to other types of Switchable optical devices, including liquid crystal devices, electrochromic devices, suspended particle devices (SPD), NanoChromics displays (NCD), organic electroluminescent displays (OELD), suspended particle devices (SPD), NanoChromics displays (NCD) or have Electromechanical Electroluminescent Displays (OELDs). The display element may be attached to a portion of the transparent body, such as a window. Tintable windows may be placed in (non-transitory) installations such as buildings, and/or in transitory vehicles such as automobiles, RVs, buses, trains, airplanes, rocket ships, helicopters, ships, or boats.

In some embodiments, a tintable window exhibits a (eg, controllable and/or reversible) change in at least one optical property of the window, eg, upon application of a stimulus. Stimulation may include optical, electrical and/or magnetic stimulation. For example, stimulation can include applying a voltage. One or more tintable windows may be used to control lighting and/or glare conditions, eg, by adjusting the transmission of solar energy propagating therethrough. One or more tintable windows can be used to control the temperature within a building, for example, by regulating the transmission of solar energy propagating therethrough. Control of solar energy can control the thermal load imposed on the interior of a facility (eg, a building). Control can be manual and/or automatic. Controls may be used to maintain one or more requested (eg, environmental) conditions, such as occupant comfort. Controls may include reducing energy consumption of heating, ventilation, air conditioning and/or lighting systems. At least two of heating, ventilation and air conditioning can be induced by separate systems. At least two of heating, ventilation and air conditioning can be induced by a system. Heating, ventilation and air conditioning can be induced by a single system (abbreviated herein as "HVAC"). In some cases, the tintable window may be responsive to (eg, and communicatively coupled to) one or more environmental sensors and/or user controls. Tintable windows can include (eg, can be) electrochromic windows. Windows may be located in a range from the interior to the exterior of a structure (eg, a facility such as a building). However, this need not be the case. Tintable windows may be operated using liquid crystal devices, suspended particle devices, microelectromechanical systems (MEMS) devices such as micro-shutters, or any technology now known or later developed that is configured to control the transmission of light through a window. Windows (eg, with MEMS devices for coloring) are described in an application entitled "MULTI-PANE WINDOWS INCLUDING ELECTROCHROMIC DEVICES AND ELECTROMECHANICAL SYSTEMS INCLUDING ELECTROCHROMIC DEVICES AND ELECTROMECHANICAL SYSTEMS DEVICES" filed on May 15, 2015. DEVICES)" in U.S. Patent Application Serial No. 14/443,353, which is incorporated herein by reference in its entirety. In some cases, one or more tintable windows may be located inside the building, such as between a conference room and a hallway. In some cases, one or more tinted windows may be used in automobiles, trains, airplanes, and other vehicles, eg, in place of passive and/or non-tinted windows.

A Particular examples of electrochromic sheets (eg, panes) are described with reference to FIGS. 1A - 1C in order to illustrate the embodiments described herein. FIG. 1A is a cross-sectional representation of an electrochromic sheet 100 starting with a glass flake 105 (see section tangent X′-X′ of FIG. 1C ). FIG. 1B shows an end view of electrochromic sheet 100 (see viewing angle YY′ of FIG . 1C ), and FIG. 1C shows a top view of electrochromic sheet 100 . Figure 1A shows the electrochromic sheet after fabrication on a glass flake 105 with the edges removed to create a region 140 around the perimeter of the sheet. The electrochromic sheet has been laser scribed and bus bars have been attached. The glass sheet 105 has a diffusion barrier 110 and a first transparent conductive oxide layer (TCO) 115 on the diffusion barrier. In this example, the edge deletion process removes both the TCO 115 and the diffusion barrier 110 , but in other embodiments only the TCO is removed, leaving the diffusion barrier intact. The TCO layer 115 is the first of two conductive layers used to form electrodes of electrochromic devices fabricated on glass flakes. In this example, the glass flake includes an underlying glass and a diffusion barrier layer. Thus, in this example, a diffusion barrier is formed, and then a first TCO, an electrochromic stack 125 (eg, having an electrochromic ionic conductor and an opposing electrode layer), and a second TCO 130 are formed. In one embodiment, the electrochromic device (electrochromic stack and second TCO) is fabricated in an integrated deposition system, wherein the glass flakes do not leave the integrated deposition system at any time during stack fabrication. In one embodiment, the first TCO layer is formed using an integrated deposition system, wherein the glass flakes do not leave the integrated deposition system during deposition of the electrochromic stack and the (second) TCO layer. In one embodiment, all layers (diffusion barrier, first TCO, electrochromic stack, and second TCO) are deposited in an integrated deposition system where the glass flakes do not leave the integrated deposition system during deposition. In this example, isolation trenches 120 are cut through TCO 115 and diffusion barrier 110 before electrochromic stack 125 is deposited. The trenches 120 are made to be expected to electrically isolate the areas of the TCO 115 that will reside under the bus bar 1 after fabrication is complete (see FIG. 1A ). This is done to reduce (eg, avoid) charge build-up and coloration of the electrochromic device under the bus bars, which may be undesirable.

After the electrochromic device is formed, an edge deletion process and additional laser scribing may be performed. 1A depicts region 140 of the device that has been removed from the peripheral region around laser scribed trenches 150 , 155 , 160 , and 165 in this example . The trenches 150 , 160 and 165 pass through the electrochromic stack and through the first TCO and diffusion barrier. The trenches 155 pass through the second TCO 130 and the electrochromic stack, but not through the first TCO 115 . Laser scribed trenches 150 , 155 , 160 , and 165 are made to isolate portions 135 , 145 , 170 , and 175 of the electrochromic device that are potentially destroyed during the edge removal process from the operable electrochromic device damage. In this example, laser scribed trenches 150 , 160 , and 165 pass through the first TCO to assist isolation devices (laser scribed trench 155 does not pass through the first TCO, otherwise it may cut bus bars 2 and The first TCO and thus electrical communication with the electrochromic stack). One or more of the lasers used in the laser scribing process may be a pulsed laser, such as a diode pumped solid state laser. For example, the laser scribing process can be performed using a suitable laser from IPG Photonics (Oxford, Massachusetts) or from Ekspla (Vilnius, Lithuania). Scribing can be performed mechanically, for example with a diamond tip. Those of ordinary skill in the art will appreciate that the laser scribing process can be performed at different depths and/or in a single process, whereby the laser cutting depth occurs during a continuous path around the perimeter of the electrochromic device Change or not change. In one embodiment, edge deletion is performed to the depth of the first TCO.

After the laser scribing is complete, power distribution units (eg, bus bars) can be attached. The power distribution unit may be penetrating or non-penetrating. For example, non-penetrating bus bar 1 is applied to the second TCO. Apply the non-penetrating bus bar 2 to an un-deposited (eg, with a mask that protects the first TCO from device deposition) devices, contact the first TCO, or in this example use an edge deletion process (eg, using an XY or Laser ablation of the XYZ galvanometer device) to remove material down to the area of the first TCO. In this example, both bus bar 1 and bus bar 2 are non-penetrating bus bars. A pass-through bus bar is a bus bar that is pressed into and through the electrochromic stack to make contact with the TCO at the bottom of the stack. A non-penetrating busbar is a busbar that does not penetrate into the electrochromic stack, but instead makes electrical and physical contact on the surface of a conductive layer (eg, TCO).

The TCO layers may be electrically connected using power distribution units (eg, bus bars). For example, wire mesh and lithography patterning methods are used to fabricate bus bars. In one embodiment, electrical communication with the transparent conductive layer of the device is established via screen printing (or using another patterning method) of the conductive ink, followed by heat curing or sintering the ink. Advantages of using the device configuration described above include, for example, simpler fabrication and less laser scribing than conventional techniques using penetrating bus bars.

After connecting the bus bars, the device is integrated into an insulating glass unit (IGU), which includes, for example, routing the bus bars and the like. In some embodiments, one or both of the bus bars are inside the finished IGU, however, in one embodiment, one bus bar is outside the seal of the IGU and one bus bar is inside the IGU. In the previous embodiment, the area 140 is used to seal with one face of the spacer used to form the IGU. Thus, wires or other connections to the bus bars run between the spacers and the glass. Since many spacers are made of conductive metals such as stainless steel (eg, containing elemental metals or metal alloys), it is desirable to take steps to reduce (eg, avoid) electrical energy between the bus bars and their connectors and the metal spacers Short circuit of communication.

As described herein, after connecting power distribution units (eg, bus bars), electrochromic sheets may be integrated into IGUs, including, for example, wiring for power distribution units (eg, bus bars) and the like. In the embodiment described herein, the two bus bars are inside the main seal of the finished IGU.

2A shows a schematic cross-sectional view of an electrochromic window integrated into IGU 200 as described with respect to FIGS. 1A - 1C . The spacer 205 is used to separate the electrochromic sheet from the second sheet 210 . The second sheet 210 in the IGU 200 is a non-electrochromic sheet, however, the embodiments disclosed herein are not so limited. For example, sheet 210 may have electrochromic devices and/or one or more coatings thereon, such as a low E coating and the like. Sheet 201 may also be laminated glass, such as depicted in Figure 2B (sheet 201 is laminated to reinforcement pane 230 via resin 235 ). The primary encapsulant 215 is between the spacer 205 and the first TCO layer of the electrochromic sheet. This primary sealing material is between the spacer 205 and the second (eg, glass) sheet 210 . The secondary seal 220 surrounds the perimeter of the spacer 205 . Bus bar wiring/leads traverse the seal to connect to the controller. The secondary seal 220 may be much thicker than the depicted thickness. These seals help keep moisture out of the interior space 225 of the IGU. It can be used to reduce (eg, prevent) escaping of argon or other (eg, inert) gases in the interior of the IGU.

Figure 3A schematically depicts an electrochromic device 300 in cross section. The electrochromic device 300 includes a substrate 302 , a first conductive layer (CL) 304 , an electrochromic layer (EC) 306 , an ion conductive layer (IC) 308 , a counter electrode layer (CE) 310 and a second conductive layer (CL) 314 . Layers 304 , 306 , 308 , 310 , and 314 are collectively referred to as electrochromic stack 320 . A voltage source 316 operable to apply a potential across the electrochromic stack 320 enables the transition of the electrochromic device from, for example, a decolorized state to a colored state (depicted). The order of the layers can be reversed with respect to the substrate.

In some embodiments, the electrochromic device comprises inorganic or organic materials. For example, electrochromic devices with distinct layers (eg, as described herein) can be fabricated as all solid state devices and/or all inorganic devices. Such devices and methods of making them are described in more detail in an application filed on December 22, 2009, entitled "Fabrication of Low-Defectivity Electrochromic Devices" and naming Mark Kozlowski et al. Inventor's US Patent Application Serial No. 12/645,111 and US Patent Application Serial No. 12, filed on December 22, 2009, entitled "Electrochromic Devices" and naming Zhongchun Wang et al as inventor /645,159, each of these applications is hereby incorporated by reference in its entirety. It should be understood that any one or more of the layers in the stack may contain any (eg, some) amount of organic material. The same applies to liquids that may be present in one or more layers, eg in small amounts. It should be understood that solid state materials may be deposited or otherwise formed by processes using liquid components, such as certain processes using sol-gel or chemical vapor deposition.

It should be understood that references to transitions between decolorized and colored states are non-limiting and represent only one example of many examples of electrochromic transitions that can be implemented. Unless otherwise specified herein (including the foregoing discussion), whenever a reference is made to a decolorized to colored transition, the corresponding device or procedure encompasses other optical state transitions, such as non-reflective to reflective, transparent to opaque, and the like. Additionally, the term "discolored" refers to an optically neutral state, such as colorless, transparent, or translucent. Unless otherwise specified herein, the "color" of an electrochromic transition is not limited to any particular wavelength or range of wavelengths. For example, the wavelength may be visible or any other wavelength disclosed herein. As understood by those skilled in the art, the selection of appropriate electrochromic and opposing electrode materials governs the associated optical transitions.

In the embodiments described herein, the electrochromic device cycles reversibly between a decolorized state and a colored state. In some cases, when the device is in a discolored state, a potential is applied to the electrochromic stack 320 such that the available ions in the stack reside primarily in the opposing electrode 310 . When the potential on the electrochromic stack is reversed, ions are transported across the ionically conductive layer 308 to the electrochromic material 306 and the material is converted to a colored state. In a similar manner, the electrochromic devices of the embodiments described herein can be reversibly cycled between different hue levels (eg, a decolorized state, a darkest state, and levels intermediate between the decolorized state and the darkest state) .

Referring again to FIG. 3A , voltage source 316 can be configured to operate in conjunction with radiation and other environmental sensors. As described herein, voltage source 316 interfaces with a device controller (not shown in this figure). Additionally, the voltage source 316 may interface with an energy management system that controls the electrochromic device according to various criteria such as time of year, time of day, and measured environmental conditions. This energy management system combined with large-area electrochromic devices (eg, electrochromic windows) can significantly reduce the energy consumption of a building.

Any material with suitable optical, electrical, thermal and mechanical properties can be used as the substrate 302 . Such substrates include, for example, glass, plastic, and mirror materials. Suitable glasses include clear or tinted soda-lime glass, including soda-lime float glass. Glass can be strengthened (eg, tempered) or untempered.

In many cases, the substrates are glass panes sized for residential window applications. The size of this pane of glass can vary widely depending on the particular needs of the dwelling. In other cases, the substrate is architectural glass. Architectural glass can be used in commercial buildings. It can be used in residential buildings; and can separate the indoor environment from the outdoor environment. In certain embodiments, the pane (eg, architectural glass) is at least about 20 inches by 20 inches. The pane may be at least about 80 inches by 120 inches. The panes may be at least about 2 mm thick, typically about 3 mm to about 6 mm thick. Electrochromic devices can be extended to substrates smaller or larger than the panes. In addition, electrochromic devices can be placed on mirror surfaces of any size and shape.

Conductive layer 304 is on top of substrate 302 . In certain embodiments, one or both of conductive layers 304 and 314 are inorganic and/or solid. Conductive layers 304 and 314 can be made of several different materials, including conductive oxides, thin metal coatings, conductive metal nitrides, and composite conductors. The conductive layers 304 and 314 are transparent at least in the wavelength range in which the electrochromic layer exhibits electrochromism. Transparent conductive oxides include metal oxides and metal oxides doped with one or more metals. Examples of such metal oxides and doped metal oxides include indium oxide, indium tin oxide, doped indium oxide, tin oxide, doped tin oxide, zinc oxide, aluminum zinc oxide, doped zinc oxide, Ruthenium oxide, doped ruthenium oxide and the like. Since oxides can be used for these layers, they are sometimes referred to as "transparent conductive oxide" (TCO) layers. Thin (eg, substantially) transparent metal coatings and combinations of TCO and metal coatings can be used.

In some embodiments, the function of the conductive layer is to spread the potential provided by the voltage source 316 over the surface of the electrochromic stack 320 to the interior regions of the stack, eg, with a relatively small ohmic potential drop. The potential can be transferred to the conductive layer via an electrical connection to the conductive layer. In some embodiments, bus bars (one in contact with conductive layer 304 and one in contact with conductive layer 314 ) provide electrical connections between voltage source 316 and conductive layers 304 and 314 . Conductive layers 304 and 314 may be connected to voltage source 316 , eg, by (eg, other) means.

The electrochromic layer 306 overlaps the conductive layer 304 . In some embodiments, electrochromic layer 306 includes inorganic and/or solid materials. The electrochromic layer may contain any one or more of several different electrochromic materials, including metal oxides. Such metal oxides include tungsten oxide (WO ₃ ), molybdenum oxide (MoO ₃ ), niobium oxide (Nb ₂ O ₅ ), titanium oxide (TiO ₂ ), copper oxide (CuO), iridium oxide (Ir ₂ O ₃ ) , chromium oxide (Cr ₂ O ₃ ), manganese oxide (Mn ₂ O ₃ ), vanadium oxide (V ₂ O ₅ ), nickel oxide (Ni ₂ O ₃ ), cobalt oxide (Co ₂ O ₃ ) and the like. During operation, electrochromic layer 306 transfers ions to and receives ions from opposing electrode layer 310 to cause optical transitions.

In some embodiments, the coloring of an electrochromic material (or a change in any optical property such as absorptivity, reflectance, and transmittance) results from reversible ion implantation (eg, intercalation) into the material and the correspondence of charge-balancing electrons caused by injection. A fraction of the ions responsible for the optical transition are irreversibly bound in the electrochromic material. Some or all of the irreversibly bound ions can be used to compensate for "blind charges" in the material. In some electrochromic materials, suitable ions include lithium ions (Li+) and hydrogen ions (H+) (protons). In some cases, other ions will be suitable. In various embodiments, lithium ions are used to generate electrochromic phenomena. Intercalation of lithium ions into, for example, tungsten oxide (WO _3-y (0<y≦~0.3)) changes tungsten oxide from transparent (decolorized state) to blue (colored state).

Referring again to FIG. 3A , in electrochromic stack 320 , ionically conductive layer 308 is sandwiched between electrochromic layer 306 and opposing electrode layer 310 . In some embodiments, the opposing electrode layer 310 includes inorganic and/or solid materials. The opposing electrode layer may comprise one or more of several different materials that act as ion reservoirs when the electrochromic device is in the decolorized state. During an electrochromic transition initiated eg by application of an appropriate potential, the opposing electrode layer can transfer some or all of the ions it holds to the electrochromic layer, thereby changing the electrochromic layer to eg a coloured state. Meanwhile, in the case of NiWO, the opposite electrode layer is colored with the loss of ions.

In some embodiments, suitable materials complementary to WO ₃ for the opposing electrode include nickel oxide (NiO), nickel tungsten oxide (NiWO), nickel vanadium oxide, nickel chromium oxide, nickel aluminum oxide, nickel manganese oxide, nickel oxide Magnesium, chromium oxide (Cr ₂ O ₃ ), manganese oxide (MnO ₂ ) and/or Prussian blue.

When the counter electrode 310 made of free nickel tungsten oxide removes the charge (transporting ions from the counter electrode 310 to the electrochromic layer 306 ), the counter electrode layer will transition from a transparent state to a colored state.

In the depicted electrochromic device, an ionically conductive layer 308 exists between the electrochromic layer 306 and the opposing electrode layer 310 . The ionically conductive layer 308 acts as a medium through which ions are transported (eg, in an electrolyte) when the electrochromic device transitions, eg, between a decolorized state and a colored state. The ionically conductive layer 308 can be highly conductive to the relevant ions for the electrochromic layer and the opposing electrode layer, and the ionically conductive layer can have sufficiently low electron conductivity that negligible electron transfer occurs during normal operation. Thin ionically conductive layers with high ionic conductivity may allow for fast ionic conduction (eg, and for high performance electrochromic devices, fast switching). In certain embodiments, the ionically conductive layer 308 includes inorganic and/or solid materials.

Examples of suitable ionically conductive layers (for electrochromic devices with distinct IC layers) include silicates, silicon oxides, tungsten oxides, tantalum oxides, niobium oxides, and/or borates. These materials can be doped with various dopants, including lithium. Lithium-doped silicon oxide includes lithium silicon aluminum oxide. In some embodiments, the ionically conductive layer includes a silicate-based structure. In some embodiments, silicon aluminum oxide (SiAlO) is used for the ion conducting layer 308 .

Electrochromic device 300 may include one or more additional layers (not shown), such as one or more passive layers. Passive layers (eg, to improve certain optical properties) may be included in electrochromic device 300 . A passive layer for providing moisture or scratch resistance may be included in the electrochromic device 300 . For example, the conductive layer may be treated with an anti-reflective or protective (eg, oxide and/or nitride) layer. Other passive layers can be used to hermetically seal the electrochromic device 300 . The hermetic seal may comprise a gas seal.

3B is a schematic cross-section of an electrochromic device in a decolorized state (or transitioned to a decolorized state). According to certain embodiments, the electrochromic device 400 includes a tungsten oxide electrochromic layer (EC) 406 and a nickel tungsten oxide counter electrode layer (CE) 410 . Electrochromic device 400 includes substrate 402 , conductive layer (CL) 404 , ion conductive layer (IC) 408 , and conductive layer (CL) 414 .

Power supply 416 is configured to apply potential and/or current to electrochromic stack 420 via suitable connections (eg, bus bars) to conductive layers 404 and 414 . In some embodiments, the voltage source is configured to apply a potential of several volts in order to drive the device to transition from one optical state to another. The polarity of the potential as shown in FIG . 3B is such that ions (in this example, lithium ions) reside primarily (as indicated by the dashed arrows) in the nickel tungsten oxide counter electrode layer 410 .

3C is a schematic cross-section of the electrochromic device 400 shown in FIG. 3B but in a colored state (or transitioning to a colored state). In Figure 3C , the polarity of the voltage source 416 is reversed, making the electrochromic layer more negative to accept additional lithium ions, and thus transition to a colored state. Lithium ions are transported across the ion-conducting layer 408 to the tungsten oxide electrochromic layer 406 as indicated by the dashed arrows. The tungsten oxide electrochromic layer 406 is shown in a colored state. The nickel tungsten oxide counter electrode 410 is shown in a colored state. As explained herein, nickel tungsten oxide becomes progressively more opaque because it gives up (deintercalates) lithium ions. In this example, there is a synergistic effect in which the transition of both layers 406 and 410 to the colored state is additive in reducing the amount of light transmitted through the stack and substrate.

As described herein, an electrochromic device may include an electrochromic (EC) electrode layer and a counter electrode (CE) layer separated by an ion-conducting (IC) layer that is highly conductive to ions (eg, and high resistance to electrons). The ionically conductive layer can reduce (eg, prevent) shorting between the electrochromic layer and the opposing electrode layer. The ionically conductive layer may allow the electrochromic and opposing electrodes to hold charge (eg, and maintain their discolored or colored state). In an electrochromic device (eg, having distinct layers), the components form a stack including an ionically conductive layer sandwiched between an electrochromic electrode layer and an opposing electrode layer. Boundaries between (eg, three) stacked components may be defined by sudden changes in composition and/or microstructure. An EC device may have (eg, three) distinct layers with (eg, two) abrupt interfaces.

According to certain embodiments, the opposing electrode and the electrochromic electrode are formed in close proximity to each other, sometimes in direct contact, without the need to deposit an ionically conductive layer separately. In some embodiments, electrochromic devices with interfacial regions rather than distinct IC layers are used. Such devices, methods of making the same, and related apparatus and software are described in US Patent No. 8,300,298, filed April 30, 2010, and US Patent Application No. 12/772,075, filed on June 11, 2010 In Ser. Nos. 12/814,277 and 12/814,279, each of the three patent applications and patents titled "Electrochromic Devices" each named Zhongchun Wang et al. as inventors and each of which is incorporated herein by reference in its entirety.

At least one window controller is used to control the tint level of the electrochromic device of the electrochromic window. In some embodiments, the window controller is capable of transitioning the electrochromic window between two hue states (levels): a bleached state and a tinted state. In some embodiments, the controller may additionally transition the electrochromic window (eg, with a single electrochromic device) to the midtone level. In some embodiments, the at least one controller includes a master controller and a local controller. In some embodiments, the at least one controller is a hierarchical control system. In some embodiments, the at least one controller includes a local controller, such as a window controller. In some disclosed embodiments, the window controller is capable of transitioning the electrochromic window to two, three, four, or more than four (eg, distinct) hue levels. In some embodiments, the window controller is capable of continuously transitioning the electrochromic window from transparent to the darkest tint level. Certain electrochromic windows allow for midtone levels by using two (or more than two) electrochromic sheets in a single IGU, each of which is a two-state sheet. This situation is described in this section with reference to Figures 2A and 2B .

As mentioned above with respect to FIGS. 2A and 2B , in some embodiments, the electrochromic window may include electrochromic device 400 on one sheet of IGU 200 and another electrochromic device 400 on another sheet of IGU 200 . These multiple EC devices in an IGU allow for more combinations of hue states. For example, if the window controller is capable of transitioning each electrochromic device between two (eg, distinct) states (eg, a discolored state and a tinted state), the electrochromic window may be capable of four distinct states (hue levels), including: a colored state in which both electrochromic devices are colored, a first intermediate state in which one electrochromic device is colored, a second intermediate state in which the other electrochromic device is colored, and two electrochromic devices in a colored state. The decolorized state in which all the chromic devices are decolorized. Embodiments of multi-pane electrochromic windows are further described in U.S. Patent No. 8,270,059, entitled "MULTI-PANE ELECTROCHROMIC WINDOWS," to which Robin Friedman et al. The patents are incorporated herein by reference in their entirety.

In some embodiments, the window controller is capable of transitioning an electrochromic window having an electrochromic device capable of transitioning between two or more tint levels. For example, a window controller may be capable of transitioning an electrochromic window to a decolorized state, one or more intermediate levels, and a tinted state. In some other embodiments, the window controller is capable of transitioning an electrochromic window incorporating an electrochromic device between any number of hue levels between a discolored state and a tinted state. Embodiments of a method and controller for transitioning an electrochromic window to one or more midtone levels are further described in the titled "Controlling Transitions in Optically Switchable Devices (Disha Mehtani et al.) CONTROLLING TRANSITIONS IN OPTICALLY SWITCHABLE DEVICES)", US Patent No. 8,254,013, which is incorporated herein by reference in its entirety.

In some embodiments, the window controller can power one or more electrochromic devices in the electrochromic window. This function of the window controller is augmented by one or more other functions described in more detail below. Local (eg, window) controllers described herein may not be limited to those controllers that have the function of powering their associated electrochromic devices for control purposes. The power supply for the electrochromic window can be separate from the window controller, where the controller has its own power supply and directs the application of power to the window from the window power supply. It may be convenient to include the power source in the window controller (eg, and configure the controller to power the window directly).

The window controller can be configured to control the function of a single window or a plurality of electrochromic windows. The window controller can control at least 1, 2, 3, 4, 5, 6, 7 or 8 tintable windows. Local (eg, window) controllers may or may not be integrated into the building control network and/or building management system (BMS). However, the window controller can be integrated into a building control network or BMS, as described herein.

4 depicts a schematic block diagram of some components of a window controller 450 and other components of a window controller system of the disclosed embodiment. Further details of the components of the window controller can be found in both naming Stephen C. Brown as inventor, both titled "CONTROLLER FOR OPTICALLY-SWITCHABLE WINDOWS" and both. Both are in U.S. Patent Application Serial Nos. 13/449,248 and 13/449,251, filed April 17, 2012, and can be found in, filed April 17, 2012, entitled "Controlling Transitions in Optically Switchable Devices." (CONTROLLING TRANSITIONS IN OPTICALLY SWITCHABLE DEVICES)", U.S. Patent No. 13/449,235 naming Stephen C. Brown et al. as inventors, and each of these patent applications and patents is incorporated by reference in its entirety. into this article.

In FIG. 4 , the illustrated components of the window controller 450 include a microprocessor 455 or other processor, a pulse width modulator 460 , one or more inputs 465 , and a computer-readable medium having a configuration file 475 (eg, ,Memory). The window controller 450 is in electronic communication with one or more of the electrochromic devices 400 in the electrochromic window via a network 480 (wired or wireless) to send instructions to the one or more electrochromic devices 400 . In some embodiments, the window controller 450 may be a local window controller that communicates with the master window controller via a network (wired or wireless).

In some embodiments, an enclosure (eg, building) may have at least one room having, for example, an electrochromic window disposed between the exterior and interior of the enclosure (eg, building). One or more sensors may be disposed (eg, located) outside or inside the enclosure (eg, outside a building and/or inside a room). In an embodiment, the output from the one or more sensors is used to control various devices in the enclosure, such as a tintable window, including the one of the electrochromic device 400 . Although the sensors of the depicted embodiment are shown as being located on the exterior vertical walls of an enclosure such as a building, this is for simplicity and the sensors may also be placed in other parts of the enclosure, such as Inside a room, on a roof, or on other surfaces to the outside. In some cases, two or more sensors may be used to measure the same input, which provides redundancy in the event that one sensor fails or has otherwise erroneous readings and/or senses the same property at different locations Remain. In some cases, two or more sensors may be used to measure different inputs, eg, to sense different properties.

5 depicts a schematic diagram (side view) of an enclosure (eg, room) 500 having an electrochromic window 505 with at least one electrochromic device. Electrochromic windows 505 are located between the exterior and interior of the building that includes room 500 . Room 500 includes window controller 450 connected to electrochromic window 505 and configured to control the tint level of the electrochromic window. External sensors 510 are located on vertical surfaces in the exterior of the building. In some embodiments, interior sensors may be used to measure ambient light in room 500 . In yet other embodiments, occupant sensors may be used to determine when an occupant is in room 500 .

External sensor 510 is a device such as a light sensor capable of detecting radiant light incident on the device from a light source such as the sun or light reflected from a surface to the sensor, particles in the atmosphere, clouds, etc. The external sensor 510 can generate a signal in the form of a current generated by the photoelectric effect, and the signal can be dependent on the light incident on the sensor 510 . In some cases, the device may detect radiant light in terms of irradiance in watts per square meter (watt/m ² ) or other similar units. In other cases, the device may detect light in the visible wavelength range in foot candles or similar units. In many cases, there is a linear relationship between these irradiance values and visible light.

In some embodiments, the external sensor 510 is configured to measure infrared light. In some embodiments, the external light sensor is configured to measure infrared light and/or visible light. In some embodiments, the external light sensor 510 may include sensors for measuring temperature and/or humidity data. In some embodiments, smart logic may use one or more parameters (eg, visible light data, infrared light data, humidity data, and temperature data) to determine the presence of occlusion clouds and/or to quantify occlusion caused by clouds, the one The parameter or parameters are determined using external sensors or received from an external network (eg, a weather station). VARIOUS METHODS OF DETECTING CLOUD USING INFRARED SENSORS DESCRIBED FILED ON OCTOBER 6, 2017, titled "INFRARED CLOUD DETECTOR SYSTEMS AND METHODS" and designating the United States and by reference in its entirety Incorporated herein in International Patent Application No. PCT/US17/55631.

The irradiance value from sunlight can be predicted based at least in part on the time of day and the time of the year due to the changing angle of sunlight on the Earth. External sensors 510 may detect radiant light in real time, taking into account reflections and occlusions due to buildings, weather (eg, cloud) changes, and the like. For example, on a cloudy day, sunlight will be blocked by clouds and the radiant light detected by the external sensor 510 will be less than on a cloudless day.

In some embodiments, there may be one or more external sensors 510 associated with a single electrochromic window 505 . The outputs from the one or more external sensors 510 may be compared to each other to determine, for example, whether one of the external sensors 510 is occluded by an object, such as a bird falling on the external sensor 510 . In some situations, it may be desirable to use relatively few sensors because some sensors may be unreliable and/or expensive. In some embodiments, a single sensor or several sensors may be used to determine the current level of radiation light from the sun impinging on the building or possibly on one side of the building. Clouds may pass in front of the sun, or construction vehicles may be parked in front of the setting sun. Such situations will result in deviations from the amount of radiant light from the sun calculated for normal exposure to the building.

External sensor 510 may be a type of light sensor. For example, the external sensor 510 may be a charge coupled device (CCD), photodiode, photoresistor, or photovoltaic cell. Those of ordinary skill in the art will appreciate that future developments in light sensors and other sensor technologies will be applicable as they measure light intensity and provide an electrical output indicative of light level.

In the disclosed embodiment, window controller 450 may instruct PWM 460 to apply voltage and/or current to electrochromic window 505 to transition the electrochromic window to one of four or more different tint levels either. In the disclosed embodiments, the electrochromic window 505 can be transitioned to at least eight different hue levels described as: 0 (brightest), 5, 10, 15, 20, 25, 30, and 35 (darkest). The hue level may correspond linearly to the visual transmittance value and the solar heat gain coefficient (SHGC) value of light transmitted through the electrochromic window 505 . For example, using the eight hue levels described above, the brightest hue level 0 may correspond to a SHGC value of 0.80, hue level 5 may correspond to an SHGC value of 0.70, hue level 10 may correspond to an SHGC value of 0.60, and hue level 15 may correspond to a SHGC value of 0.50, a hue level of 20 may correspond to a SHGC value of 0.40, a hue level of 25 may correspond to an SHGC value of 0.30, a hue level of 30 may correspond to an SHGC value of 0.20, and a hue level of 35 (darkest) This corresponds to a SHGC value of 0.10.

Window controller 450 or a master controller in communication with window controller 450 may use any one or more predictive control logic components to determine desired hue levels based at least in part on signals from external sensor 510 and/or other inputs allow. Window controller 450 may instruct PWM 460 to apply voltage and/or current to electrochromic window 505 to shift it to a desired hue level.

In some embodiments, the window controllers described herein are suitable for integration with a building management system (BMS) or within/part of a building management system. A BMS may be a computerized control system installed in a building that controls (eg, monitors) the mechanical and/or electrical equipment of the building, such as ventilation, lighting, electrical systems, elevators, fire protection systems, and/or security systems. A BMS may consist of hardware (eg, including interconnection to one or more computers via communication channels) and associated software. The BMS may maintain conditions in the building according to preferences (eg, requests) set by users such as occupants and/or by the building manager. For example, BMS can be implemented using a local area network such as Ethernet. The software may be based at least in part on, for example, Internet Protocol and/or open standards. An example is software from Tridium Corporation of Richmond, Virginia. One communication protocol for use by the BMS is BACnet (Building Automation and Control Network). The BMS can be configured for this (class ) communication protocol.

BMS can be commonly found in large buildings. The BMS can at least function to control the environment within the building. For example, the BMS and/or control system may control temperature, carbon dioxide levels and/or humidity within the building, eg, using one or more sensors. There may be mechanical devices controlled by the BMS, such as heaters, air conditioners, blowers, vents and/or the like. To control the building environment, the BMS may attenuate and/or switch any of these various devices on and off, eg, under defined conditions. In some embodiments, a core function of a BMS may be to maintain a comfortable environment for the occupants of a building, eg, while minimizing heating and cooling costs/demands. Thus, the BMS can be used to control and/or optimize the synergy between various systems, eg, to save energy and/or reduce building operating costs.

In some embodiments, the control system (or any portion thereof, such as a window controller) is integrated with the BMS. The window controller can be configured to control one or more electrochromic windows (eg, 505 ) or other tintable windows. In some embodiments, the window controller is incorporated into the BMS (eg, and the BMS controls both the function of tintable windows and other systems of the building). In one example, the BMS can control the functions of all building systems including one or more partitions of tintable windows in the building.

In some embodiments, at least one (eg, each) tintable window of the one or more partitions includes at least one solid state and/or inorganic electrochromic device. In one embodiment, at least one (eg, each) of the tintable windows of the one or more partitions is an electrochromic window having one or more solid state and/or inorganic electrochromic devices. In one embodiment, the one or more tintable windows include at least one all solid state and inorganic electrochromic device, but may include more than one electrochromic device, eg, where each sheet or pane of the IGU is tintable . In one embodiment, the electrochromic window is as described in US Patent Application No. 12/851,514, filed August 5, 2010 and entitled "Multipane Electrochromic Windows" Polymorphic Electrochromic Window, which application is incorporated herein by reference in its entirety. 6 depicts a schematic diagram of an example of a building 601 and a BMS 605 that manages several building systems, including security systems, heating/ventilation/air conditioning (HVAC), the building's lighting, electrical systems, elevators, fire protection systems, and the like similar. Security systems may include magnetic card access, turnstiles, solenoid actuated door locks, surveillance cameras, burglar alarms, metal detectors, and/or the like. Fire protection systems may include fire alarm and fire suppression systems, including plumbing controls. The lighting system may include interior lighting, exterior lighting, emergency warning lights, emergency exit signs and/or emergency floor exit lighting. The power system may include primary power, backup generators, and/or an uninterruptible power supply (UPS) grid.

In the example shown in FIG. 6, BMS 605 manages window control system 602 . Window control system 602 is a distributed network of window controllers, including master controller 603 , floor (eg, network) controllers 607a and 607b , and local (eg, terminal or leaflet) controllers 608 , such as window controller. The terminal or leaflet controller 608 may be similar to the window controller 450 described with respect to FIG. 4 . For example, master controller 603 may be proximate to BMS 605 , and at least one (eg, each) floor of building 601 may have one or more network controllers 607a and 607b , and at least one of the building (eg, each) Each) window has its own terminal controller 608 . In this example, each of the controllers 608 controls a particular electrochromic window of the building 601 . The window control system 602 communicates with the cloud network 610 to receive data. For example, the window control system 602 may receive scheduling information from a clear sky model maintained on the cloud network 610 . Although main controller 603 is depicted in FIG. 6 as being separate from BMS 605 , in another embodiment main controller 603 is part of or within BMS 605 . FIG. 6 shows an example of a hierarchical control system 602 .

At least one (eg, each) of the controllers 608 can be in a separate location from the electrochromic window it controls, or integrated into the electrochromic window. For simplicity, only ten electrochromic windows of building 601 are depicted as being controlled by master window controller 602 . In a setting (eg, a facility that includes a building), there may be a large number of electrochromic windows in the building controlled by the window control system 602 . Described herein are the advantages and features of incorporating an electrochromic window controller as described herein with a BMS.

One aspect of the disclosed embodiment is a BMS that includes a multipurpose electrochromic window controller, eg, as described herein. By incorporating feedback from at least one (eg, local) controller, the BMS can provide, for example, enhanced: 1) environmental control; 2) energy savings; 3) safety; 4) flexibility of control options; 5) Improved reliability and longevity of other systems due to less reliance and therefore less maintenance on them; 6) Information availability and/or diagnostics; 7) Effective use and feedback from staff higher productivity; or any combination thereof. In some embodiments, the BMS does not exist, or the BMS may exist but may not communicate with the control system (eg, with the master controller), or communicate with the control system (eg, with the master controller) at a high level. In some embodiments, maintenance on the BMS will not interrupt control of the electrochromic window.

In some cases, the system of BMS 605 or building network 1200 may operate according to a daily, monthly, quarterly or yearly schedule. For example, any of the devices operatively (eg, communicatively) coupled to a BMS such as lighting control systems, window control systems, HVAC, and/or security systems may be based on a schedule such as a 24-hour schedule Operations (eg, consider when people are in a facility (eg, a building) during the workday). At night, the building may enter an energy saving mode, and during the day, the system may operate in a manner that minimizes energy consumption by the facility (eg, building) while providing occupant comfort. As another example, the system may shut down or enter an energy saving mode during a holiday period.

In some embodiments, the enclosure includes an area bounded by at least one structure. At least one structure may comprise at least one wall. An enclosure may contain and/or enclose one or more sub-enclosures. At least one wall may comprise metal (eg, steel), clay, stone, plastic, glass, plaster (eg, gypsum), polymer (eg, polyurethane, styrene, or vinyl), asbestos, fibers Glass, concrete (eg reinforced concrete), wood, paper or ceramic. At least one wall may contain wires, bricks, blocks (eg, cinder blocks), tiles, drywall, or framing (eg, steel frames).

In some embodiments, the closure includes one or more openings. The one or more openings may be reversibly closed. One or more openings may be permanently open. The basic length dimension of the one or more openings may be relatively small relative to the basic length dimension of the walls defining the closure. The basic length dimension may include the diameter, length, width or height of the bounding circle. The surface of the one or more openings may be relatively small relative to the surface of the wall defining the closure. The open surface may be a percentage of the total surface of the wall. For example, the open surface may measure about 30%, 20%, 10%, 5% or 1% of the wall. Walls can include floors, ceilings, or side walls. The closable opening may be closed by at least one window or door. The enclosure may be at least a portion of the facility. The enclosure may contain at least a portion of the building. The buildings can be private buildings and/or commercial buildings. A building can contain one or more floors. A building (eg, its floors) may include at least one of the following: rooms, halls, foyers, attics, basements, balconies (eg, interior or exterior balconies), stairwells, hallways, elevator shafts, facades, mezzanine levels , attic, garage, porch (eg, enclosed porch), patio (eg, enclosed patio), cafeteria, and/or plumbing. In some embodiments, the enclosure may be stationary and/or movable (eg, a train, plane, ship, vehicle, or rocket).

In some embodiments, a plurality of devices (eg, sensors, emitters, and/or tintable windows) are operably (eg, communicatively) coupled to the control system. The control system may include a hierarchy of controllers. A device may include transmitters, sensors, or windows (eg, IGUs). The device can be any device as disclosed herein. At least two of the plurality of devices may be of the same type. For example, two or more IGUs may be coupled to the control system. At least two of the plurality of devices may be of different types. For example, sensors and transmitters can be coupled to a control system. The plurality of devices may sometimes include at least 20, 50, 100, 500, 1000, 2500, 5000, 7500, 10000, 50000, 100000 or 500000 devices. The plurality of devices may have any number of devices between the foregoing numbers (eg, from 20 devices to 500,000 devices, from 20 devices to 50 devices, from 50 devices to 500 devices, from 500 devices to 2,500 devices) devices, from 1,000 devices to 5,000 devices, from 5,000 devices to 10,000 devices, from 10,000 devices to 100,000 devices, or from 100,000 devices to 500,000 devices). For example, the number of windows in a floor may be at least 5, 10, 15, 20, 25, 30, 40 or 50. The number of windows in a floor can be any number between the foregoing (eg, from 5 to 50, from 5 to 25, or from 25 to 50). Devices can sometimes be in multistory buildings. At least a portion of the floors of the multi-story building may have devices controlled by the control system (eg, at least a portion of the floors of the multi-story building may be controlled by the control system). For example, a multi-story building may have at least 2, 8, 10, 25, 50, 80, 100, 120, 140 or 160 floors controlled by the control system. The number of floors (eg, devices therein) controlled by the control system can be any number between the foregoing numbers (eg, from 2 to 50, from 25 to 100, or from 80 to 160). A floor may have an area of at least about 150 square meters, 250 square meters, 500 square meters, 1000 square meters, 1500 square meters, or 2000 square meters (m ² ). Floors can have an area between any of the foregoing floor area values (eg, from about 150 square meters to about 2000 square meters, from about 150 square meters to about 500 square meters, from about 250 square meters feet to about 1000 square meters or from about 1000 square meters to about 2000 square meters).

BMS scheduling can be combined with geographic information. The geographic information may include the latitude and longitude of an enclosure (eg, a building). The geographic information may include information about the direction in which the sides of the building are facing. Using this information, different enclosures (eg, rooms) on different sides of the building can be controlled in different ways. For example, in winter, for an east-facing room of a building, the window controller may instruct the window to have no tint in the morning, causing the room to warm due to sunlight shining in the room, and because of the lighting from the sunlight, the lighting control panel The indicator light can be dimmed. The west-facing windows can be controlled by the room occupant in the morning because the hue of the upper windows on the west side may not affect energy savings. However, the operating modes of east-facing windows and west-facing windows can be switched at night (eg, when the sun goes down, the west-facing windows are not tinted to allow daylight in for heat and illumination).

The following describes an example of a building (eg, similar to building 601 in FIG. 6 ) that includes a building network or BMS, tintable windows for the exterior windows of the building (eg, integrating the interior of the building). windows separated from the outside of the building) and several different sensors. Light from the exterior windows of a building has an effect on interior lighting in the building at about 20 feet or about 30 feet from the window. Spaces in buildings that are at least about 20 feet or at least about 30 feet from exterior windows receive very little light from exterior windows. Such spaces in buildings remote from external windows may be illuminated by the building's lighting system.

The temperature inside a building can be affected by outside light and/or outside temperature. For example, on a cold day and where the building is heated by a heating system, rooms closer to doors and/or windows will lose heat faster than the interior areas of the building and will be cooler than the interior areas.

For external sensors, the building may include external sensors placed on the roof or outer walls of the building. Alternatively, the building may include an exterior sensor associated with at least one (eg, each) exterior window (eg, room 500 as described with respect to FIG. 5 ) and/or at least one of the building (eg, room 500 ) external sensors on each) side. External sensors on at least one (eg, each) side of the building can track the irradiance on one side of the building as the sun changes position throughout the day.

In some embodiments, the received output signals include signals indicative of energy or power consumption of heating systems, cooling systems and/or lighting fixtures within the building. For example, energy and/or power consumption of a building's heating system, cooling system, and/or lighting devices may be monitored to provide signals indicative of energy or power consumption. The device is operatively coupled (eg, interfaced or attached) to the electrical circuits and/or wiring of the building, eg, to enable such monitoring. Electrical systems in a building may be installed so that heating, cooling, and/or lighting from individual enclosures (eg, a room within a building or a group of rooms within a building) may be controlled (eg, monitored) power consumed.

A tint command may be provided to change the tint of the tintable window to the determined tint level. For example, referring to Figure 6 , this may include the master controller 603 issuing commands to one or more network controllers 607a and 607b , which in turn issue commands to at least the control building An endpoint (eg, local) controller 608 for one (eg, each) window. The terminal controller 608 may apply voltage and/or current to the window to drive the hue change as commanded. The terminal controller can control any of the devices disclosed herein (eg, sensors, transmitters, HVAC, and/or tintable windows).

In some embodiments, a building that includes tintable (eg, electrochromic) windows and a BMS may participate or participate in a demand response program (eg, run by utilities that provide electricity to the building). The program may be a program that reduces the energy consumption of the building in anticipation of peak loads. Utilities can issue warning signals before peak loads are expected. For example, the warning can be issued a day, in the morning, or about an hour before the expected peak load occurs. For example, on a hot summer day, peak loads can be expected when the cooling system/air conditioner draws a lot of power from the utility. The warning signal may be received by the building's BMS or by a window controller configured to control electrochromic windows in the building. This warning signal may be an override mechanism that disengages the window controller from the system. The BMS can then instruct the window controller to switch the appropriate electrochromic device in the electrochromic window 505 to a dark tone level, assisting in reducing the power draw of the cooling system in the building when peak loads are expected.

In some embodiments, tintable windows for exterior windows of a building (eg, windows that separate the interior of the building from the exterior of the building) may be grouped into one or more zones, where in a similar manner the Tinable windows. For example, groups of electrochromic windows on different floors of a building or on different sides of a building can be in different partitions. For example, on the first floor of a building, all east-facing electrochromic windows can be in zone 1, all south-facing electrochromic windows can be in zone 2, and all west-facing electrochromic windows can be In zone 3, and all north facing electrochromic windows can be in zone 4. As another example, all electrochromic windows on the first floor of a building may be in zone 1, all electrochromic windows on the second floor may be in zone 2, and all electrochromic windows on the third floor Windows can be in partition 3. As yet another example, all east facing electrochromic windows can be in zone 1, all south facing electrochromic windows can be in zone 2, all west facing electrochromic windows can be in zone 3, and all south facing electrochromic windows can be in zone 3 North electrochromic windows are available in zone 4. As yet another example, east-facing electrochromic windows on one floor may be divided into different zones. Any number of tintable windows on the same side and/or different sides and/or different floors of the building can be assigned to a partition. In embodiments where individual tintable windows have independently controllable zones, a combination of zones of individual windows can be used to form tinted zones on a building facade, for example where an individual window may or may not tint all of its zones. Zoning may be specified based on: geographic orientation, floors in a building, specified utilities of enclosures in which they are located, temperature of enclosures in which they are located, radiation through windows (eg, solar radiation), weather and/or occupancy rate (or the projected occupancy level of the enclosure in which it is placed).

In some embodiments, at least two (eg, all) of the electrochromic windows in the partition may be controlled by the same window controller or the same group of window controllers. In some other embodiments, at least two (eg, all) of the electrochromic windows in the partitions may be controlled by different window controllers.

In some embodiments, at least two tintable (eg, electrochromic) windows in a partition may be controlled by one of receiving output signals from an optical (eg, transmittance) sensor and/or multiple window controllers. In some embodiments, the transmittance sensor may be mounted proximate the window in the partition. For example, the transmittance sensor may be mounted in or on a frame included in the partition containing the IGU (eg, mounted in or on a sash portion such as a mullion or rung). In some other embodiments, a tintable (eg, electrochromic) window in a partition including a window on a single side of a building may receive one or more output signals from an optical (eg, transmittance) sensor window controller control.

In some embodiments, users of rooms in the second partition (eg, building managers and/or occupants) may manually instruct (using a tint command, a clear command, or from a user console such as a BMS) command) the tintable (eg, electrochromic) windows in the second partition (eg, the controlled partition) to enter a tint level such as a tinted state (level) or a clear state. In some embodiments, the electrochromic windows in the first partition (eg, the master partition) remain in a self (eg, transmittance) sense when the tint level of the windows in the second partition is overridden with this manual command. under the control of the output received by the detector. The second partition may remain in the manual command mode for a period of time and then return to be under control of the output from the transmittance sensor. For example, after receiving the overwrite command, the second partition may remain in manual mode for an hour, and then may return to being under control of the output from the transmittance sensor.

In some embodiments, a building manager, an occupant of a room in the first partition, or other personnel may manually instruct (using a tint command or a command from a user console such as a BMS) the first partition (eg, the main control partition) into a hue level such as a tinted state or a clear state. In some embodiments, the electrochromic windows in the second partition (eg, controlled partitions) remain at the control output from the external sensor when the tint level of the windows in the first partition is overridden with this manual command Down. The first partition may remain in the manual command mode for a period of time and then return to be under control of the output from the transmittance sensor. For example, after receiving the overwrite command, the first partition may remain in manual mode for an hour, and then may return to being under control of the output from the transmittance sensor. In some other embodiments, the electrochromic window in the second partition may remain at the tint level it was at when it received the manual overwrite for the first partition. The first partition may remain in the manual command mode for a period of time and then both the first and second partitions may return to be under control of the output from the transmittance sensor.

Regardless of whether the window controller is a stand-alone window controller or is interfaced with a building network, the tint of a tintable window can be controlled using any of the methods described herein for controlling a tintable window.

In some embodiments, the window controllers described herein include components for wired or wireless communication between the window controller, sensors, and (eg, separate) communication nodes. Wireless and/or wired communication can be achieved through a communication interface (eg, directly) interfacing with the window controller. This interface may be native to the microprocessor or provided via additional circuitry that enables these functions.

A separate communication node for wireless communication may be, for example, another wireless window controller, a terminal, an intermediate or main window controller, a remote control device or a BMS. Using wireless communication in the window controller for at least one of: programming and/or operating the electrochromic window 505 ; collecting data from the EC window 505 from the various sensors and protocols described herein; And/or use the electrochromic window 505 as a relay point for wireless communication. The data collected from the electrochromic window 505 may include count data such as the number of times the EC device has been activated; the efficiency of the EC device over time, current, voltage; data collection time and/or date; and the like. Window properties may include tintable materials (eg, electrochromic structures) or pane properties (eg, thickness, length, and width).

In one embodiment, wireless communication is used, at least in part, to operate the associated electrochromic window 505 , eg, via infrared (IR) and/or radio frequency (RF) signals. In some embodiments, the controller will include a wireless protocol chip, such as Bluetooth, EnOcean, WiFi, Zigbee, and the like. The window controller can be configured for wireless communication via a network. Input to the window controller may be entered by the end user directly or manually at the wall switch via wireless communication, or the input may be from the BMS of the building of which the electrochromic window is a component.

In one embodiment, when the window controller is part of a distributed (eg, and hierarchical) network of controllers, wireless communication is used to transfer data to the Data is transferred from at least one (eg, each) of the plurality of electrochromic windows and from at least one (eg, each) of the plurality of electrochromic windows. For example, referring again to FIG. 6 , main controller 603 wirelessly communicates with at least one (eg, each) of network controllers 607a and 607b , which in turn wirelessly communicate with terminal controller 608 , the terminal controllers are associated with electrochromic windows. The main controller 603 can communicate with the BMS 605 wirelessly. In one embodiment, the communication of at least one level of the window controllers is performed wirelessly. In other embodiments, the communication may comprise wired communication.

In some embodiments, more than one wireless communication mode is used in the window controller decentralized network. For example, the master window controller may communicate wirelessly with the intermediate controller via WiFi and/or ZigBee, while the intermediate controller communicates with the end controller via Bluetooth, ZigBee, EnOcean, and/or other protocols. In another example, the window controller has a redundant wireless communication system to flexibly select end users for wireless communication.

For example, wireless communication between the main window controller and/or the intermediate window controller and the terminal window controller provides the advantage of avoiding the need for hard communication wires. The same is true for wireless communication between the window controller and the BMS. In one aspect, these wireless communications in action are suitable for data transfer to and/or from electrochromic windows for operating the windows and providing data to, for example, a BMS to optimize the environment in a building and energy saving. Window site data and feedback from the sensors are used synergistically for this optimization. For example, particle-level (window-by-window) microclimate information is fed into the BMS to optimize the various environments of the building.

7 are components of a system 700 for controlling the function (eg, transitioning to different tint levels) of one or more tintable windows in a building (eg, building 601 shown in FIG . 6 ), according to an embodiment An example of a block diagram. System 700 may be one of the systems managed by a BMS (eg, BMS 605 shown in FIG. 6 ), or may operate independently of the BMS.

System 700 includes a window control system 702 having a network of window controllers that can send control signals to tintable windows to control their function. System 700 includes a network 701 in electronic communication with a master controller 703 . Predictive control logic, other control logic and instructions, sensor data, and/or scheduling information about the clear sky model for controlling the function of the tintable window may be communicated to the host controller 703 via the network 701 . The network 701 can be a wired and/or wireless network (eg, a cloud network). In one embodiment, the network 701 can communicate with the BMS to allow the BMS to send instructions for controlling the tintable windows to the tintable windows in the building via the network 701 .

The system 700 includes an EC device 780 for a tintable window (not shown) and an optional wall switch 790 , both of which are in electronic communication with the main controller 703 . In the example illustrated here, the main controller 703 may send control signals to the EC device 780 to control the tint levels of the tintable windows with the EC device 780 . Each wall switch 790 communicates with the EC device 780 and the main controller 703 . An end user (eg, an occupant of a room with a tintable window) can use the wall switch 790 to input overriding tint levels, and can use other functions of the tintable window with the EC device 780 .

In FIG. 7 , a window control system 702 is depicted as a distributed network of window controllers including a main controller 703 , a plurality of network controllers 705 in communication with the main controller 703 , and groups of complex A terminal or louver controller 710 . Each group of multiple terminal or louver controllers 710 communicates with a single network controller 705 . The components of system 700 in FIG. 7 may be similar in some respects to those described with respect to FIG. 6 . For example, main controller 703 may be similar to main controller 603 and network controller 705 may be similar to network controller 607 . Each of the window controllers in the distributed network of FIG. 7 may include a processor (eg, a microprocessor) and/or a computer-readable medium in electrical communication with the processor.

In Figure 7 , each split or terminal window controller 710 communicates with a single tintable window EC device 780 to control the tint level of the other tintable windows in the building. In the case of an IGU, a leaf or terminal window controller 710 may communicate with multiple on-chip EC devices 780 of the IGU to control the tint level of the IGU. In some embodiments, at least one (eg, each) leaf or terminal window controller 710 may be in communication with a plurality of shadeable windows. Leaflet or terminal window controller 710 may be integrated into the tintable window or may be separate from the tintable window it controls. The lobe and terminal window controller 710 in FIG. 7 may be similar to the terminal or lobe controller 608 in FIG. 6 and/or may be similar to the window controller 450 described with respect to FIG. 4 .

In some cases, the signal from the wall switch 790 may override the signal from the window control system 702 . Under other conditions (eg, high demand conditions), the control signal from the window control system 702 may override the control signal from the wall switch 1490 . Each wall switch 790 also communicates with the splitter or terminal window controller 710 to send information about the control signals sent from the wall switch 790 (eg, time, date, tint level requested, etc.) back to the master window control device 703 . In some cases, the wall switch 790 may be manually operated (eg, also). In other cases, the wall switch 790 may be wirelessly controlled by the end user using a remote device (eg, a mobile phone, tablet, etc.) that uses infrared (IR) and/or radio frequency (RF) signaling, for example, to control the Wireless communication of signals. In some cases, wall switch 790 may include a wireless protocol chip, such as Bluetooth, EnOcean, WiFi, ZigBee, and the like. Although the wall switch 790 depicted in FIG. 7 is located on the wall, other embodiments of the system 700 may have switches located elsewhere in the room.

Conventional smart window and/or shading control systems actively model shadows and reflections on buildings, which are cumbersome and inefficient for computing resources at the building. The system architecture described herein may not require the control system to actively generate a model of the building. Indeed, building site-specific models may be generated and/or maintained on a cloud network or other network separate from the control system. For example, neural network models (eg, deep neural networks (DNN) and/or long short-term memory (LSTM)) can be initialized, retrained, and/or networked in the cloud or separately from the window control system Other real-time models running on the network and tint schedule information from these models can be pushed to the window control system 840 . Example DNN architectures that can be used in some implementations include Convolutional Neural Networks (CNN), Recurrent Neural Networks (RNN), Deep Belief Networks (DBN), and the like.

The tint schedule information can be used to define rules derived from these models and pushed to the window control system. The window control system can utilize tinting schedule information (eg, derived from a predefined model customized for the building in question) to make final tinting decisions to implement at tintable windows. 3D models can be maintained on a cloud-based 3D modeling platform that, for example, can generate visuals of 3D models to allow users to manage inputs for setting and customizing building locations and application to tinted windows. Corresponds to the final tone state. Once the tint schedule information is loaded into the window control system, modeling calculations may not be required to take up the computing power of the control system. The tint schedule information resulting from any changes to the model can be pushed to the window control system when needed (eg, on demand or in a predetermined schedule). It should be understood that although the system architecture is described herein with respect to controlling tintable windows, other components and systems at the building may additionally or alternatively be controlled by this architecture.

In various implementations, the system architecture includes modules (eg, cloud-based) to set up and/or customize 3D models of enclosures (eg, building sites). In some embodiments, the cloud-based 3D modeling system uses a building model as input to initialize a 3D model of a building location, such as an Autodesk® Revit model or other industry standard building model. A 3D model in its simplest form includes the exterior surfaces of the building's structure (including window openings) and a stripped-out version of the building's interior (with only the floor and walls). More complex models may include the exterior surfaces of objects surrounding the building and more detailed features of the interior and exterior of the building. System architecture may include (eg, cloud-based) clear sky modules that assign reflective or non-reflective properties to exterior surfaces of objects in 3D models, define interior 3D footprints, assign IDs to windows and/or at least partially The windows are grouped into partitions based on input from users and/or sensors. Time-varying simulations of the resulting clear sky 3D models (eg, 3D models with configuration data with assigned properties) can be used to determine the direction of sunlight at different locations of the sun under clear sky conditions and take into account (i) solar radiation from the building site. Shadows and/or reflections of objects, (ii) sunlight entering the space of the building and/or (iii) the intersection of the 3D projection of sunlight and the three-dimensional occupancy in the building. In some embodiments, the clear sky module uses this information to determine whether certain conditions exist, such as glare conditions, direct reflection conditions, indirect reflection conditions, and/or passive conditions, for a particular occupancy area (eg, from the occupant's perspective) heating conditions. In some embodiments, the clear sky module determines the clear sky hue state of at least one (eg, each) partition in at least one (eg, each) time interval based at least in part on: (I) a particular condition is the existence of that time; (II) the hue state assigned to the condition and/or (III) the priority of different conditions in the presence of multiple conditions. The hue schedule information (eg, annual schedule) may be communicated (eg, pushed) to, eg, a master controller of a control system at the building. Based at least in part on sensor data, such as measurements from infrared sensors and/or light sensors (eg, sensing light in the visible spectrum), the control system may determine at least one (eg, each) Weather-based hue status of the partition in at least one (eg, each) time interval. The control system then determines the minimum of the weather-based hue state and the clear sky hue state to set the final hue state, and sends hue commands to implement the final hue state at the partitions of the tintable windows. Thus, in some embodiments, the window control system does not model the building or 3D parameters around and inside the building, it is done off-line, and thus the computing power of the control system is available for other tasks, such as based at least in part on the The hue state is applied by the model and/or other input received by the control system.

In some embodiments, a control system (eg, a master controller) utilizes one or more modules (eg, as described herein). A module may facilitate controlling the tint of at least one tintable window (eg, by providing at least a portion of control logic). The modules may be based, at least in part, on sensor data collected from real-world sensors (eg, light sensors, IR sensors, or any other sensor disclosed herein). The module may predict sensor values at future times, eg, using machine learning (eg, artificial intelligence), weather forecasts, history sensor measurements, and/or real-time sensor measurements. Mods can utilize physics simulation, for example for weather forecasting. Processing sensor data includes performing sensor data analysis. Sensor data analysis may include at least one rational decision-making process and/or learning. Sensor data analysis can be used to adjust the tint of the tintable window. Sensor data analysis can be used to adjust the environment, such as by adjusting one or more components that affect the environment of the enclosure. Data analysis may be performed by machine-based systems (eg, circuitry). The circuitry may belong to a processor. Sensor data analysis can leverage artificial intelligence. Sensor data analysis may rely on one or more models (eg, mathematical models, such as weather forecast models). In some embodiments, sensor data analysis includes linear regression, least squares fitting, Gaussian program regression, kernel regression, nonparametric multiplicative regression (NPMR), regression trees, local regression, semiparametric regression, isotonic regression, multiple Variable Adaptive Regression Splines (MARS), Logistic Regression, Robust Regression, Polynomial Regression, Stepwise Regression, Ridge Regression, Lasso Regression, Elastic Net Regression, Principal Component Analysis (PCA), Singular Value Decomposition, Fuzzy Measure Theory, Pole Borel measure, Han measure, Risk neutral measure, Lebesgue measure, Grouped data handling method (GMDH), Naive Bayes classifier, k-Nearest Neighbor algorithm (k-NN) ), support vector machines (SVM), neural networks, support vector machines, classification and regression trees (CART), random forests, gradient boosting, generalized linear model (GLM) techniques or deep learning techniques.

8 is a diagram depicting the systems and uses involved in initializing and customizing a model maintained in a cloud network 801 and controlling tintable windows of a building based at least in part on output, such as rules from the model, according to various implementations A schematic illustration of the architecture 800 of the above. The system architecture 800 includes a cloud-based 3D model system 810 in communication with a cloud-based clear sky module 820 , wherein the combination of 810 and 820 is referred to as module A. In one embodiment, module A provides input to window control system 840 . The 3D model system 810 may initialize and/or modify the 3D model of the building site and communicate the data of the 3D model to the clear sky module 820 . The 3D model initialized by the 3D model system includes the surrounding structures and the outer surfaces of other objects at the building site and the building stripped of all but walls, floors and outer surfaces. The cloud-based clear sky module 820 can assign attributes to 3D models to generate clear sky 3D models, such as one or more of a glare/shadow model, a reflection model, and/or a passive heating model. Cloud-based systems may communicate with each other and with other applications via a (eg, cloud) network, eg, using an application programming interface (API). Both the cloud-based 3D model system 810 and the clear sky module 820 include logic as described herein. It should be understood that the logic of these cloud-based modules (as well as other modules described herein) may be stored in a computer-readable medium (eg, memory) such as a server of a cloud network. One or more processors (eg, on a server in a cloud network) can communicate with the computer-readable medium, eg, to execute instructions to perform logical functions. In one embodiment, the window control system 840 receives input from module B described herein. In another embodiment, the window control system 840 receives input from modules A, C1 and/or D1.

The clear sky module 820 can use the 3D model of the building site to generate simulations of different positions of the sun under clear sky conditions over time to determine glare, shadows and/or from one or more objects at and around the building site reflection. For example, the clear sky module 820 can generate clear sky glare/shadow models and/or reflection models. The clear sky module may utilize a ray tracing engine to determine direct sunlight through window openings of buildings based at least in part on shadows and reflections in clear sky conditions. The clear sky module 820 may utilize shadow and reflection data to determine the presence of glare, reflections, and/or passive heating conditions at the occupancy area of the building (ie, likely locations of occupants). The cloud-based clear sky module 820 may determine an annual schedule (or other selected time) for the hue status of at least one (eg, each) of the partitions of the building based at least in part on one or more of these conditions part). The cloud-based clear sky module 820 communicates (eg, pushes) the hue schedule information to the window control system 840 .

In some embodiments, window control system 840 includes a network of window controllers, such as the networks described in FIGS. 6 and 7 . The control system 840 communicates with the partitions of tintable windows in the building, which are depicted in FIG. 8 as a series of partitions from partition 1 872 to partition n 874 . The window control system 840 determines the final tint state and sends tint commands to control the tint state of the tintable windows. The final hue state may be determined based at least in part on (eg, annual) schedule information, sensor data, and/or weather feed data. As described with respect to the illustrated system architecture 800 , the control system 840 may not generate models (or otherwise invest computing power) upon modeling. In some embodiments, models that may be specific to the building site are created, customized, and stored in the cloud network 801 . The predefined tint schedule information may be communicated (eg, pushed) to the window control system initially and optionally only when the 3D model needs to be updated (eg, building layout changes, new objects in surrounding area, or the like).

System architecture 800 may include a graphical user interface (GUI) 890 , eg, for communicating with clients and/or other users, providing application services, reports, visual effects of 3D models, receiving input for setting up 3D models and/or receive input for customizing 3D models. The visual effects of the 3D model may be provided to and/or received from the user, eg, via a GUI. In the example shown in FIG. 8 , the illustrated user includes location operations 892 involved in troubleshooting the location, and is able to review the visuals and edit the 3D model. Users include a Customer Success Manager (CSM) 894 who can review visual effects and 3D models for live configuration changes. The user includes a client configuration portal 898 that communicates with various clients. Through the customer configuration portal 898 , the customer can review various visuals of the data mapped to the 3D model and provide input to change the configuration at the building site. Some examples of input from the user may include spatial configuration, such as occupancy area, 3D object definition at the building site, hue state for specific conditions, and priority of conditions. Some examples of outputs provided to users include visual effects of data on 3D models, standard reports, and performance assessments of buildings. Certain users are depicted for illustrative purposes. It should be understood that other or additional users may be included.

Although many examples of system architectures are described herein in which 3D model systems, clear sky modules, and neural network models reside on a cloud network, in another implementation, one or more of these modules and models may not necessarily require Residing on the cloud network. For example, the 3D model system, clear sky module, and or other modules or models described herein may reside on a stand-alone computer or other computing device that is separate from the window control system and separate from the window. Control system communication. As another example, the neural network models described herein may reside on a window controller, such as a master window controller or a network window controller.

In some embodiments, the computing resources used to train and execute the various models (eg, DNN and LSTM models) and modules of the system architecture described herein include: (1) local resources of the window control system; ( 2) a remote source separate from the window control system; or (3) a shared resource. In a first state, the computing resources used to train and execute various models and modules reside in the master control of a distributed network of window controllers (such as the distributed network of window control system 602 in FIG. 6 ) controller or one or more window controllers. In the second state, computing resources for training and executing various models and modules reside on remote resources separate from the window control system. For example, computing resources may reside on servers on external third-party networks or on servers that can rent cloud-based resources, such as are available on cloud network 801 in FIG. 8 . As another example, computing resources may reside on servers at a site that are separate computing devices separate from and in communication with the window control system. In the third state, the computing resources used to train and execute the various models and modules reside on shared resources (both local and remote). For example, remote resources (such as rentable cloud-based resources available on cloud network 801 in Figure 8 ) perform daily retraining operations of the DNN model and/or LSTM model at night, and local resources (such as the master window controller or group of window controllers of window control system 602 in FIG. 6 ) executes the real-time model on the day when a tint decision needs to be made.

In various embodiments, the system architecture has a cloud-based 3D modeling system that can use a 3D modeling platform to generate 3D models (eg, solid models, surface models, or wireframe models) of building locations. Various commercially available programs are available as 3D modeling platforms. An example of such a commercially available program is the Rhino® 3D software produced by McNeel North America of Seattle Washington. Another example of a commercially available program is the Autocad® computer-aided design and drafting software application from Autodesk® of San Rafael, California. A further example of a tool that can be used to implement aspects of the invention is a reflective/direct glare tool, available as WRLD3d from WRLD, Dundee city DD1 1NJ, United Kingdom, and available as WRLD3d. IMMERSIFY! VR in Revit and Rhino is available from the Immersify Project at https://immersify.eu.

In some embodiments, the 3D model is a three-dimensional representation of a building, and optionally other objects at the location of the building with tintable windows. Building site means the area around the building of interest. The zone can be defined to include all objects around the building that will create shadows and/or reflections on the building. A 3D model may include the exterior surfaces of the building and other objects surrounding the building and a three-dimensional representation of the building stripped of all surfaces except walls, floors and exterior surfaces. A 3D model system can generate a 3D model, eg, using a 3D model such as Revit or other industry standard building models, automatically and by stripping the modeled building of all surfaces except the walls, floors, and surfaces with the exception of window openings. Any other objects in the 3D model will automatically be stripped of all components except the outer surface. As another example, a 3D model may be generated from scratch using 3D modeling software. An example of a 3D model of a building site with three buildings is shown in FIG. 9 .

In some embodiments, the model of the enclosure includes the architecture of the enclosure (eg, including one or more fixtures). A model may include a 2D and/or 3D representation of an enclosed volume (eg, a facility including a building). Models can identify one or more materials contained in these fixtures. Models may include Building Information Modelling (BIM) software (eg, Autodesk Revit) products (eg, files). BIM products allow users to design buildings using parametric modeling and drawing components. In some embodiments, BIM is a computer-aided design (CAD) paradigm that allows intelligent, 3D, and/or parametric object-based design. A BIM model can contain information about the entire life cycle of a building from concept to construction to decommissioning. This functionality may be provided by the underlying relational database architecture of the BIM model which may be referred to as a parameter change engine. BIM products can use .RVT files to store BIM models. Parametric objects (whether 3D building objects (such as windows or doors) or 2D drawing objects) can be called families, saved in .RFA files and imported into the RVT database. There are many sources of pre-drawn RFA libraries.

BIM (eg, Revit) allows users to create parametric components in the graphical "Family Editor". Models capture the relationships between components, views, and annotations so that any changes to components are automatically propagated to keep the model consistent. For example, moving walls updates adjacent walls, floors, and roofs, corrects placement and values of dimensions and annotations, adjusts floor areas reported in schedules, redraws sections, and more. BIM may facilitate continuous linking, updating and/or coordination between models of a facility and (eg, all) documents, eg, to simplify instant updates and/or instant corrections of models. The concept of bidirectional associativity between components, views and annotations can be a feature of BIM.

The recent installation of large numbers of tintable windows (such as electrochromic windows, sometimes referred to as "smart windows") in large-scale buildings has led to increased demands on complex control systems involving, for example, extensive computing resources. For example, a large number of tintable windows deployed in large scale buildings may have a large number of partitions (eg, 10,000) requiring complex reflection and glare models. As these tintable windows continue to gain acceptance and are more widely deployed, they will require more complex systems and models that will involve large amounts of data.

The system architecture described herein uses a 3D modeling platform that can be implemented locally, remotely, and/or in the cloud to generate 3D model visuals. Such models include, for example, glare/shadow models, reflection models, and passive heating models. 3D models can be used to visualize the effects of sunlight on the interior and exterior of buildings. Figure 10 is an example of the visual effects of glare, shadows, reflections and heating present along the exterior surfaces of a building according to the path of the sun at a particular time of day. Visual effects may be produced in clear sky conditions, eg, based at least in part on clear sky models for parts of buildings. Visual effects can be used to assess and control glare in single and/or multiple occupancies and partitions in interior spaces of any size on any floor of a building, taking into account the exterior of the building and its possible exposure to the sun's path. Features (this overhang, upright, etc.). The 3D representation can take into account primary reflections, secondary reflections, single reflections and/or multiple reflections from external objects and complex curved and convex shapes of buildings; and their effects on occupied areas and partitions within buildings. Visual effects may be used to model the presence and/or effect of heat caused by direct radiation, radiation reflected and/or diffused by external objects and buildings, and radiation occluded by external objects and buildings.

The clear sky module includes logic that can be implemented to assign properties to the 3D model to generate a clear sky 3D model. The clear sky module can include logic that can be used to generate other models to determine various conditions such as glare/shadow models, reflection models, and passive heating models. These models of building locations can be used to generate (eg, annual) schedules for the tone status of the building's zoning, which schedules are communicated (eg, pushed) to control systems at the building, such as to make ( For example, final) coloring decisions. With this system architecture, most of the data can be kept on the network (eg, in the cloud). Maintaining a model on a network (eg, in the cloud) may allow easy access and/or customization by customers and other users. For example, the visuals of the various models can be sent to the user to allow them to review and send input, such as to set up and customize the model and/or override the final shading schedule at the building or other system functions. For example, a user may use visual effects to manage inputs used to assign rules to clear sky models, such as in partition management and/or window management, for example, as part of location setup and/or customization.

In some embodiments, the system architecture includes a GUI for interfacing with various clients and other users. The GUI may provide application services and/or reports to the user, and/or receive input from the user for various models. For example, the GUI may provide the user with visual effects of various models. The GUI may provide interfaces for zone management, window management, and/or occupancy definition to set up clear sky models. The GUI may provide an interface for entering priority data, reflective properties of outer surfaces, override values, and/or other data. The user can use the GUI to customize the space of the 3D model, for example after viewing the visuals of the clear sky model of the building site. Some examples of customization include: (1) re-structuring the building site (moving the building, correcting exterior surface properties) to see changes in reflection, glare and heating conditions or the coloring of the building's zoning; (2) re-structuring Internal structure of the building (walls, floors) and external shell to see how changes will affect the tone state; (3) Manage zoning of windows; (4) Change materials used in the building to see changes in reflective properties and reflections Corresponding changes in model and tone state; (5) changing shading priority to see changes in tone state as mapped to a three-dimensional (3D) model of a building; (6) overriding tone state in schedule data; (7) Modified buildings at building locations and/or (8) added new conditional models.

The system architecture described herein includes a control system that includes a network of controllers that control the tint levels of tintable windows (eg, disposed in one or more partitions) at a building. Some examples of controllers that may be included in the system architecture window control system 840 are described with respect to FIGS . 6-8 . Other examples of window controllers are described in US Patent Application Serial No. 15/334,835, filed October 26, 2016, and entitled "CONTROLLERS FOR OPTICALLY-SWITCHABLE DEVICES", which The application is hereby incorporated by reference in its entirety.

Window control system 840 includes control logic for making tinting decisions and sending tint commands to change tint levels of tintable windows. In some embodiments, the control logic includes module A having a cloud-based 3D model system 810 and a cloud-based clear sky module 820 and module B described further below, wherein module B has one or more light Module C of sensor values and/or receiving signals from module D having one or more infrared sensor values (see Figure 27). Module C may include one or more light sensors that obtain light sensor readings or may be obtained from one or more light sensors residing, for example, in a multi-sensor device or a sky sensor The sensor receives the signal with the raw light sensor reading. Similarly, module D may include one or more infrared sensors and/or ambient temperature sensors that obtain temperature readings or may be sourced from, for example, resident in a multi-sensor device Or one or more infrared sensors in the sky sensor receive a signal with raw temperature measurements.

In some embodiments, shading decisions (eg, based on real-world sensor data) may be referred to herein as "intelligent" modules. Smart modules may include modules A, B, C, C1, D and/or D1. The smart module may rely, at least in part, on sensor data that occurred in the past. Smart modules may rely, at least in part, on sensors from real entities (eg, any of the sensors or sensor modules disclosed herein, such as light sensors, infrared sensors, and/or sky sensing device) sensor data. Smart modules may not rely on virtual sensors (eg, VSS), eg, as disclosed herein.

FIG. 11 is an illustrative example of data flow communicated between some of the systems of system architecture 800 shown in FIG. 8 . As shown, module A (including 810 and 820 ) provides its information to window control system 840 . In one implementation, the control logic of the window control system 840 receives one or more inputs from module B and sets at least one based at least in part on the outputs received from module A and/or module B (eg, The final tone state of each) partition. In another implementation shown in FIG. 28 , the control logic of the window control system 840 receives one or more inputs from module C1 and module D1 and is based, at least in part, from module A, module C1 and module D1 The output received by group D1 sets the final tone state of at least one (eg, each) partition.

12 is a schematic illustration of an example of certain logical operations implemented by clear sky module 820 to generate hue schedule information based at least in part on clear sky conditions. In this illustrated example, the clear sky module applies the hue state assigned to at least one (eg, each) condition to the condition value, and then applies the priority from the priority data to determine at least one (eg, each) The hue state of the partition at a specific time. In another example, the clear sky module may apply the priority from the priority data to a condition value to determine the condition to apply, and then apply the hue state of that condition to determine at least one (eg, each) partition at a particular time The hue state of the interval. In Figure 12 , the top table titled "Table 1" is an example of a table of condition values determined by the clear sky module, including glare conditions, direct reflection conditions, and passive heating for zone 1 at time intervals during the day The value of the condition. In this example, the condition value is a binary value of 0/1 whether the condition exists at different times during the day: 0 - the condition does not exist; and 1 - the condition does exist. Figure 12 includes a second table titled "Table 2" showing an example of the hue state output from the clear sky module. This hue state is assigned to each partition for each condition. For example, for glare conditions, assign zone 1 to hue 4; for reflective conditions, assign zone 1 to hue 3; and for passive heating conditions, assign zone 2 to hue 1. When a condition is true, the clear sky module assigns a hue state to apply to that condition. Priority data refers to a list of priorities used to apply conditions to each partition of a building. In some cases, priority data can be configured by the user. The third table, titled "Table 3," illustrated in Figure 12 , is an example of a configurable priority table (eg, configurable by the user) that lets the system know which condition takes priority. In this example, for each partition of the building, priorities are given for glare conditions, direct reflection conditions, and passive heating conditions. The bottom graph in Figure 12 is an example of the hue state determined at partition 1 based on priority data from Table 3 applied to the condition values in top Table 1 and Table 2 for a portion of the day.

13 is a schematic depiction of model data flow through a cloud-based system through an embodiment of the system architecture. The 3D model is generated on the 3D platform. The 3D model includes a 3D version of the building defining window openings, walls and floors. The outer surfaces of surrounding objects (and their reflective properties) can be added to the 3D model. Window openings in the 3D model can be grouped into zones and/or given names.

For example, information is received from the user via the user part GUI. For example, the user may highlight or otherwise identify the desired hue of the 2D area of the occupied parts and the floor of the space of the 3D model of the building (or in the architectural model used to generate the 3D model) for such occupied parts condition. A user may use the GUI to define the hue state of at least one (eg, each) footprint associated with at least one (eg, each) condition, such as a direct glare condition and a reflective condition. The user can input a user height between ground level up to the user's eye height, which can be used to generate a 3D volume of the 2D area to generate a 3D volume of the occupied area. In one embodiment, if the user does not input the height, the height is preset (eg, 6 feet). The clear sky module conditional logic can be used to generate various conditional models including, for example, glare/shadow models, reflection models, and/or heating models. At least one of these conditional models can be used to generate (eg, annual) schedule information that is communicated to the window control system.

In some embodiments, the 3D model of the building site is initialized during the site setup procedure. In some implementations, the user is given the ability to modify the model (eg, via a GUI), such as to customize controls for tintable windows and/or other systems in a building. These customizations can be reviewed by the user through the visuals on the 3D modeling platform. For example, a client or other user can view after customization what structure has been designed for a building and how it will operate on a given day and provide a "what if" scenario. Different users can review the same 3D model stored on the network (eg, in the cloud), eg, to compare and/or discuss options that will cater to multiple users. For example, the CSM may review user parts, hue status during clear sky conditions, eg, by a facility manager, based on conditions, priorities, and/or expected behavior.

In some embodiments, the location setting procedure includes generating a 3D model of the building location and/or assigning attributes to elements of the 3D model. A 3D model platform can be used to generate a 3D model of a building site, for example, by stripping unnecessary features from the architectural model of the building and creating the exterior surfaces of objects surrounding the building.

14 is an example flow diagram of operations involved in initializing a 3D model on a 3D model platform, according to various implementations. In one embodiment, the 3D model is automatically generated from the architectural model of the building and/or surrounding structure by stripping the architectural model of all extra elements. For example, an Autodesk® Revit model of a building can be taken and stripped of all elements except walls, floors, and surfaces including outside window openings. Such operations may be performed by a 3D modeling system. In Figure 14 , the 3D modeling system receives an architectural model of a building with tintable windows for the structure and other objects surrounding the building at the building site ( 1410 ). At operation 1420 , the 3D modeling system strips away all but the structural elements representing the window openings, walls, floors, and exterior surfaces of the building with tintable windows. At operation 1430 , the 3D modeling system builds the exterior surfaces of the building and other objects around the building, or removes all elements except the exterior surfaces from the surrounding objects. The output of operation 1430 is a 3D model of the building site. An example of a 3D model of a building site is shown in FIG. 9 . In some embodiments, the model is released from at least one (eg, all) non-structural elements.

15 is a flowchart of operations involved in assigning attributes to a 3D model, generating a conditional model, and other operations involved in generating clear sky schedule information, according to some embodiments. One or more of these operations may be implemented using the logic of the clear sky module. As depicted, the input to the operation is the 3D model of the building site from the 3D modeling system. At operation 1510 , reflective or non-reflective properties are assigned to surface elements of objects surrounding the building of the 3D model of the building site. These reflection properties will be used to generate reflection models to evaluate conditions. At 1520 , a unique window ID is assigned to each window opening of the 3D model. In this window management operation, window openings are mapped to unique window/controller IDs. In one implementation, these mappings may be verified and/or revised based at least in part on input from window commissioning when installed in a building. At operation 1530 , the window openings in the 3D model are grouped into partitions and partition IDs and/or names are assigned to the partitions. In this partition management operation, the window openings in the 3D model are mapped to partitions. At 1540 , a 3D footprint in the model is generated and assigned a hue state. For example, the user can identify the 2D occupancy area on the floor of the 3D model and the eye height of the occupant, and the logic of the clear sky module can generate a stereoscopic of the 3D occupied area to the eye height to generate the 3D area. At operation 1550 , a clear sky model to apply is determined, and the model is run to determine a 3D projection of sunlight through the window opening. In this model management operation, various clear sky models, such as glare/shadow models and reflection models, are generated according to one embodiment. The Clear Sky module includes a ray tracing engine that determines the direction of sunlight rays based, at least in part, on the sun's different positions in the sky during a full day or other time of the year, and from objects surrounding the building. The location and reflection properties of the outer surface determine the direction and intensity of reflection. From these determinations, a 3D projection of direct sunlight passing through a window opening in the 3D model can be determined. At 1560 , the amount and duration of any intersection of the 3D projection of sunlight from the model with the 3D footprint is determined. At 1570 , a condition is evaluated based, at least in part, on the nature of the intersection determined at operation 1560 . At operation 1580 , priority data is applied to the condition values to determine the hue status of at least one (eg, each) partition of the building over time (eg, in a (eg, annual) schedule). These tint states based at least in part on clear sky conditions are communicated to the window control system.

In some embodiments, at least one (eg, each) window opening is assigned a unique window identification number (ID) corresponding to its local window controller during setup of the 3D model of the building site. Assigning a window opening to a window ID maps the window opening to a window controller. A window ID effectively represents a window controller that can be grouped into partitions. After a window and its controller are installed in a building, a commissioning operation can be used to determine which window is installed in which location and paired with which window controller. These associations from the debugger can then be used to compare and verify the mappings in the 3D model and/or update the mappings in the configuration data of the 3D model. An example of a debugger that can determine such a mapping is described in International Patent Application No. 1, filed on November 20, 2017, entitled "AUTOMATED COMMISSIONING OF CONTROLLERS IN A WINDOW NETWORK". In PCT/US17/62634, this application is hereby incorporated by reference in its entirety. The mapping of window openings to window IDs may also be modified based at least in part on other user customizations.

In one embodiment, the user can select a window opening and assign a unique window id in the 3D model on the 3D platform. Figure 16 is an example of this implementation as applied to fourteen (14) window openings in a floor of a building. As shown, the user has assigned window IDs 1 to 14 to these window openings.

In some embodiments, at least one (eg, each) partition of the building includes one or more tintable windows. Shaderable windows can be represented as openings in the 3D model. One or more of the shadeable windows in the partition will be controlled to behave in the same way. This means that if the occupancy associated with one of the windows in the partition experiences a particular condition, all windows will be controlled to react to that condition. Configuration data with properties of the 3D model include zone properties such as name, glass SHGC and maximum internal radiation. An occupant can (eg, manually) override the inclusion of a window in a partition.

During partition management as part of location setup or customization of the 3D model, the user can define window openings that will be grouped together into partitions and assign properties to the defined partitions. 17A is an example of an interface on a 3D modeling platform that allows the user to select the window openings shown in FIG . 16 to group together (map to) partitions and name the partitions. As shown, openings 1, 2, and 3 are defined as "Partition 1," openings 4-7 are defined as "Partition 2," and openings 8-14 are defined as "Partition 3." In one aspect, a user can combine partitions so that multiple partitions function in the same way. Figure 17B is an example of an interface on a 3D modeling platform that allows a user to combine multiple partitions from Figure 17A . As shown, "Partition 1" and "Partition 2" are grouped together.

18 is an example of an interface that may be used by a user to map the unmapped space of a 3D model to a particular modeled partition. As shown, the user has selected the spaces of "Office 1", "Office 2", "Office 3" and "Office 4" to map to "Zone 1". In this example, the windows associated with these spaces would be associated with "Partition 1". In one embodiment, the user may select the "Review Mapping" button to visualize the mapped windows of the space in "Zone 1" on the 3D model of the building site.

During partition management, at least one (eg, each) partition is assigned a partition property. Some examples of zone properties include: zone name (user defined), zone id (system generated), window ID, glass SHGC, maximum allowable radiation into the space in watts per square meter. 19 is an example of an interface that may be used by reviewing properties assigned to at least one (eg, each) partition.

As used herein, occupied area refers to a three-dimensional volume that is likely to be occupied or occupied during a particular period of time. Occupancy areas (eg, meeting rooms) are defined during site setup and can be redefined during customization. Defining an occupancy area may involve defining a three-dimensional volume by three-dimensionalizing a two-dimensional area to occupant eye height and assigning properties to the occupancy area. Some examples of properties include footprint name, glare hue state (hue state in the presence of glare conditions), direct reflected hue state (hue state of directly reflected radiation at different levels), and/or indirect reflection hue state (different The hue state of the indirectly reflected radiation at the level).

In certain embodiments, the footprint is created on a 3D modeling platform. The user may draw or otherwise define the user part on the floor or other surface (eg, table top) of the 3D model as one or more two-dimensional shapes (eg, polygons) and define occupant eye height. The clear sky module may define a three-dimensional occupancy area as a three-dimensionalization of a two-dimensional object from the surface to the occupant's eye level (eg, lower eye level or upper eye level). An example of a two-dimensional four-sided user part drawn on a floor of a 3D model is shown in FIG. 20A . An example of a three-dimensional footprint created by stereoscopicting the two-dimensional object in FIG. 20A to upper eye level is shown in FIG. 20B .

In certain implementations, a glare/shadow model, a direct reflection model, and an indirect reflection model are generated based at least in part on the 3D model. These models can be used to determine the 3D projection of sunlight over time through window openings in the 3D model based at least in part on clear sky conditions. In some embodiments, a ray tracing engine is used to simulate the direction of sunlight rays at the sun location during at least one (eg, each) time interval. Simulations may be run to evaluate different glare conditions in at least one (eg, each) of the building's partitions, such as base glare conditions (direct radiation intersecting the occupied area), direct reflective glare conditions (from directly reflective surfaces) single bounce to occupied area) and/or indirect reflective glare conditions (multiple bounces from indirect reflective surfaces to occupied area). In some embodiments, the simulation assumes clear sky conditions and can account for shadows in space and reflections from external objects around buildings. The simulation determines the value of glare and other conditions in time intervals over a one-year or other time period. The schedule data may include the value and/or hue of at least one (eg, each) of at least one of the conditions (eg, each) of at least one (eg, every) time interval (eg, every 10 minutes) within a time period such as a year condition.

In some embodiments, the clear sky module includes a method to determine at least one (eg, each) of the buildings during at least one (eg, each) time interval (eg, every ten minutes) of a time period such as a year. Whether different conditions exist at the zone (eg, glare, reflections, passive heating). For at least one (eg, each) time interval, the clear sky module may output schedule information for values of these conditions and/or associated hue states for at least one (eg, each) partition. The condition value can be, for example, a binary value of 1 (condition does exist) or 0 (condition does not exist). In some cases, the clear sky module includes determining the direction of sunlight rays (direct or reflected) based at least in part on where the sun is at different times.

In one embodiment, glare conditions are assessed based at least in part on multiple glare regions from a model in a single footprint. For example, light projections may intersect different occupancy areas within a single occupancy area. In one aspect, the condition is evaluated based at least in part on a plurality of elevation angles in a single partition.

In some embodiments, the determination of the glare condition is based on the intersection of the 3D projection of sunlight from the glare (no shadows) model and/or the direct reflection (one bounce) model with the 3D footprint. In some embodiments, the positive determination of the base glare from the glare model is based on the total intersection % and intersection duration with the 3D footprint. In some embodiments, the determination of reflected glare based at least in part on the reflection model is based on the intersection duration.

In some embodiments, the clear sky module includes a method for evaluating the presence of a glare condition based at least in part on objects surrounding the building and at least in part on a glare (no shadows) model and/or a direct reflection (one bounce) model logic.

According to some embodiments, for at least one (eg, each) partition, a logical self-glare model determines whether a 3D projection of direct sunlight through a partition's window opening intersects any three-dimensional footprint in the partition. If Intersection % is greater than Minimum % of Total Intersection (minimum overlap threshold from window projection into occupied area before glare conditions are considered) and Intersection Duration is greater than Minimum Intersection Duration (minimum time an intersection must occur before it becomes noticeable) amount), the glare condition value (eg, 1) and the hue state associated with the glare condition are returned. If the logical self-glare model determines that the 3D projection of direct sunlight through the window opening does not intersect any of the 3D occupancy areas in the partition, such as the partition is in shadow, the glare condition value (eg, 0) is returned and associated with the no-glare condition Linked tonal state. The logic takes the maximum hue state of the partitions that can be linked together. If there is no intersection, returns the lowest hue state (for example, hue 1). The occupancy area can be pre-determined (eg, using a 3D model of an enclosed volume (eg, facility)). Occupancy of a zone may be determined by sensors and/or transmitters. The sensor may be an occupancy sensor. Sensors and/or transmitters may include geolocation technology (eg, ultra-wideband (UWB) radio waves, Bluetooth technology, global positioning system (GPS), and/or infrared (IR) radiation). Occupancy can be determined using a microchip (eg, including sensors and/or transmitters). Occupancy can be determined using spatial mapping. Occupied areas can be determined using, for example, identification tags of occupants including microchips, sensors, and/or transmitters.

In one implementation, for at least one (eg, each) time interval, the logic determines whether the sun is interacting with any three-dimensional footprint for at least one (eg, each) partition (set of window openings) of the tintable window. (eg, directly) intersect. If it intersects with either occupied area at the same time, the output is that the condition does exist. If none of the occupied areas intersect, the condition does not exist.

Figure 21 is an example of a simulation using a glare/shadow model that does not return glare conditions using basic glare. In this example, the simulation results in a low total amount of intersection of glare with the 3D footprint, and the glare does not persist for a long time throughout the day such that the clear sky module does not return to glare conditions.

Figure 22 is an example of a simulation using a direct reflection (one bounce) model that returns the glare condition using glare from a direct one bounce reflection. In this example, the simulation yields a high total intersection with the 3D footprint and extended periods of glare occur during the day such that the glare value is returned.

The clear sky module includes logic for evaluating the presence of reflective conditions under clear sky conditions, based at least in part on the model, and for determining a minimum state to keep internal radiation below a maximum allowable internal radiation. The logic determines radiation conditions based at least in part on direct normal radiation hitting the window opening of the partition. In some embodiments, the logic determines the hue state based at least in part on the clearest hue state that can keep normal radiance below a defined threshold for that partition.

In some embodiments, the logic determines the external normal radiation on the tintable window from the 3D model, and calculates for at least one (eg, each) hue by multiplying the determined external radiation level by the glass SHGC Internal Radiation of State. In some embodiments, the logic compares the maximum internal radiance of the partition with the calculated internal radiance for at least one (eg, each) of the hue states, and selects the brightest that is lower than the maximum internal radiance of that partition Calculated hue state. For example, the outer normal radiation from the model is 800, and the maximum inner radiation is 200, and T1 SHGC=.5, T2=0.25, and T3=0.1. The logic calculates the internal radiation for at least one (eg, each) hue state by multiplying the determined external radiation level by the glass SHGC: Calc T1 (800)*0.5 = 400, Calc T2 (800)* 0.25 = 200, and Calc T3 (800)*0.1 = 80, the symbol "*" indicates the mathematical operation "multiplication". In some embodiments, the logic will select T2 because T2 is brighter than T3.

In another implementation, the logic determines whether the sun has a single bounce from an external object for at least one (eg, each) partition of the window (eg, a set of openings). If there is a reflection to any occupied area, the reflection condition does exist. If the reflection is not on any occupied area, the reflection condition does not exist.

In certain implementations, the clear sky module includes logic for evaluating the presence of passive heating conditions that set a darker tint state in the partitioned windows based at least in part on output from the clear sky model. The logic can determine from the clear sky model the external solar radiation hitting the tintable window under clear sky conditions. The logic may determine the estimated clear air heat entering the room based at least in part on external radiation on the tintable window. If the logic determines that the estimated clear air heat entering the room is greater than the maximum allowable value, then the passive heating condition exists and a darker tint state for the zone can be set based at least in part on the passive heating condition. The maximum allowable value may be set based, at least in part, on the outside temperature of the building and/or user input. In one example, if the outside temperature is low, the maximum allowable outside radiation may be set very high to allow increased levels of passive heat to enter the building space.

23 is an example of a flowchart of actions and procedures for implementing user input to customize a clear sky 3D model of a building site, according to one aspect . These location editing operations can be implemented by logic on the clear sky module 820 shown in FIG. 8 . The properties of the clear sky model can be edited (customized), defined and/or redefined at any time (including real-time). The user may type input, eg, via a GUI. In the flowchart, the procedure begins by opening the 3D model ( 2202 ). The user may then have the option to select at least one section for editing and/or select at least one user part for editing ( 2210 , 2220 ). In some embodiments, if the user chooses to edit a partition, the user may regroup ( 2212 ) the windows defined to that partition, rename the partition ( 2214 ), and/or edit the partition's allowable internal radiation or other properties ( 2212 ) 2216 ). In some embodiments, if the user selects a user part to edit ( 2220 ), then (i) the user can edit the user preferences to select a glare model or reflection model to map to the user part ( 2222 ) and/or (ii) Delete User Parts ( 2224 ) and/or Add User Parts ( 2226 ). Once an edit is made or multiple edits are made, the user submits the changes, eg to update the clear sky 3D model of the building site ( 2230 ). These changes may be used to generate new scheduling data based at least in part on the revised clear sky 3D model. Schedule data can be exported and communicated to the window control module ( 2240 ).

In some implementations, the system architecture includes a GUI that allows a user to make changes to properties of the clear sky model to view changes to the model and/or changes to scheduling data in a visual on the 3D modeling platform. The visual effects of the building location on the 3D modeling platform can be used for customization purposes.

In one example, the GUI may include a slider or other interface that allows the user to: (I) (eg, quickly) simulate periodic (eg, daily) changes in the sun's path; and/or (II) enable the Visualization of glare, shadows, and/or heating caused by the sun over a period of time (eg, a day).

Except for the visual effects of (a) direct and/or indirect reflections, (b) glare, (c) shadows, and/or (d) heating on or at one or more parts of an enclosure (eg, a building) , the tint state of a window can also be visualized via the interior and/or exterior views of the window. The window tint may be determined by control logic, eg, as described herein. For example, for at least one (eg, each) time and/or location of the sun, the user may visualize the window tint and/or changes to it by control logic. The user may use these visual effects, for example, to verify proper operation of the model and/or control logic.

In some embodiments, module A embodies control logic and/or rules for controlling glare and reflectivity in a building under clear sky conditions. Sometimes, tint decisions made by Module A alone can result in a non-optimal tint being applied to the window (eg, because the clear sky module used by Module A does not take into account the weather and any weather changes). In one embodiment, weather changes are addressed through the use of additional module B.

24 depicts an example of a window control system 2600 with control logic implemented by a window control system 2600 that communicates tint instructions to transform tintable windows within one or more partitions in a building. At operation 2620 , control logic determines a final tone level for at least one (eg, each) window and/or partition based at least in part on the rules output by Module A and Module B. For example, in one embodiment, the window control system 2600 includes a master controller that implements control logic to make shading decisions and communicate the final tint level of at least one (eg, each) partition to the control The local (eg, window) controller for a partition's shadeable windows. In one embodiment, at least one (eg, all) of the tintable windows is an electrochromic window that includes at least one electrochromic device. For example, at least one (eg, each) tintable window may be an insulating glass unit having two glass sheets, at least one of the sheets having an electrochromic device thereon. The control logic is executed by one or more processors of the window control system.

FIG. 25 is another representation of a window control system 2700 that includes a window controller 2720 , such as a master controller or a local window controller. Window control system 2700 includes control logic implemented by one or more components of window control system 2700 (eg, other controllers). As illustrated, window controller 2720 receives tint schedule information (eg, embedded in rules) from other components of window controller system 2700 according to the illustrated control logic.

In the example shown in FIG. 25 , the control logic includes logic embodied by module B 2710 . Module B 2710 is configured to forecast weather conditions at a particular geographic portion of a location at a future time. In one embodiment, predictions are made based at least in part on site-specific measurements provided by module C 2711 and module D 2712 . In one embodiment, a forecast of weather conditions is provided in the form of one or more rules that can be used to initiate a window hue change at a current time, so that the transition is completed at a future time, such that for weather conditions predicted to occur at a future time, Optimize interior light intensity, glare and reflections at future times. Tonal shifts occur in anticipation of future conditions. Thereby, to the observer, it appears as if the hue in the window is controlled in response to immediate or near-instant changes in weather conditions. Module B includes an LSTM (univariate) submodule 2710a , a post-mapping to tone value processing submodule 2714 , a DNN (multivariate) module 2710b , a binary probability submodule 2716 , and a voting submodule 2786 . The illustrated control logic includes module A 2701 with a 3D model and a clear sky model, module C 2711 with logic for determining raw and/or filtered light sensor values based on light sensor readings, a module C 2711 with logic for determining raw and/or filtered light sensor values based on Module D 2712 of the logic for IR and/or ambient temperature readings to determine raw and/or filtered IR sensor and ambient sensor values , and Module E 2713 with an unsupervised classifier sub-module. Module B may receive (eg, minute and/or real-time) data from one or more sensors related to weather (eg, as disclosed herein). Module B may receive data regarding any forecast (eg, overall) weather changes from a third party (eg, a weather forecast agency). Module B may receive predicted sensor data (eg, from a VSS sensor). The predicted sensor values may utilize artificial intelligence (eg, any of the types of artificial intelligence described herein).

In one embodiment, the values from module C 2711 are provided to module B 2710 in the form of raw and/or filtered values (eg, signals) representing measurements by one or more sensors the current environmental conditions. The sensor may be an optical sensor. The sensor may include a light sensor. Optical sensors detect wavelengths in the visible spectrum. In one embodiment, raw and/or filtered values (eg, signals) are provided as rolling averages of a plurality of light sensor readings (eg, filtered) taken at different sample times, where at least one (eg, filtered) , each) The sensor reading is the maximum measurement obtained by the sensor. In one embodiment, at least one (eg, each) sensor reading includes an instant irradiance reading. In one embodiment, raw and/or filtered values (eg, signals) are provided as rolling averages of (eg, filtered) sensor readings acquired at different sample times, where at least one (eg, each ) The sensor reading is the maximum value of the measurements taken by the sensor at different times. In one embodiment, raw and/or filtered values (eg, signals) are provided as a (eg, filtered) rolling average of a plurality of light sensor readings disposed at successive different locations, wherein at least one (eg, filtered) , each) The sensor reading is the maximum measurement obtained by the sensor. Sensors placed in succession may have contact or overlapping viewing angles. Sensors arranged in succession may form a single row, for example along an arch or along a circle.

In one embodiment, the values from module D 2712 are provided to module B 2710 in the form of raw and/or filtered values (eg, signals) representing values generated by one or more infrared (IR) sensors The current environmental conditions measured by the detector. In one embodiment, raw or filtered values (eg, signals) are provided as a filtered rolling median of multiple infrared sensor readings taken at different sample times, at least one (eg, each) of the readings is the minimum measurement value obtained by one or more infrared sensors. In one embodiment, infrared sensors are positioned at different locations, and wherein raw and/or filtered values are provided as a filtered rolling median of a plurality of infrared sensor readings taken at different locations (eg, ,Signal).

In one embodiment, the infrared sensor measurement value and/or the ambient temperature sensor measurement value includes: sky temperature reading ( T _sky ), ambient temperature reading (for example, from the local sensor at the building ( T _amb ) or from a weather feed ( T _weather ) and/or the difference between T _sky and _Tamb . A filtered infrared sensor is determined based at least in part on a sky temperature reading ( T _sky ) and an ambient temperature reading from the local sensor ( T _amb ) or an ambient temperature reading from a weather feed ( T _weather ) value. Sky temperature readings can be obtained by infrared sensors. Ambient temperature readings may be obtained by one or more ambient temperature sensors. Ambient temperature readings can be received from various sources. For example, ambient temperature may be communicated from one or more ambient temperature sensors onboard an infrared sensor and/or a separate temperature sensor such as a multi-sensor device at a building reading. As another example, ambient temperature readings may be received from a weather feed (eg, supplied by a third party such as a weather forecast agency).

In one embodiment, module D 2712 includes an ambient temperature reading (T amb ) to use cloudy offset values and sky temperature readings ( T _sky ) and ambient temperature readings from local sensors ( T _amb ) or weather feeds Logic to calculate the filtered IR sensor value from the difference (delta (Δ)) between the temperature reading ( T _weather ) and/or the sky temperature reading and the ambient temperature reading. In some embodiments, the cloudy offset value corresponds to a temperature offset that will be used by logic in module D to determine a threshold value for cloudy conditions. The logic of module D may be executed by one or more processors of the control system (eg, by a network controller and/or by a main controller). The logic of module D may be executed by one or more processors of a sensor device including one or more light sensors (eg, and infrared sensors and/or light sensors).

At operation 2810 , the processor performing the operations of module D receives as input the sensor reading of the current time. Sensor readings may be received via a communication network at the building, eg, from a sensor device (eg, a rooftop multi-sensor device). Received sensor readings may include sky temperature readings ( T _sky ) and/or ambient temperature readings (eg, from local sensors at buildings ( _Tamb ) or from weather feeds ( T _weather ) and / or reading of the difference (Δ) between T _sky and _Tamb ). The ambient temperature reading ( T _amb ) from a local sensor at the building may be obtained from an ambient temperature sensor onboard and/or separate from the sensor device measurement value. Ambient temperature sensor readings can (eg, also) come from weather feeds.

In one implementation, module D 2712 receives (and uses) measurements taken by two or more IR sensor devices at a building (eg, rooftops and/or multi-sensor devices) raw sensor readings, at least one (eg, each) IR sensor device has an onboard ambient temperature sensor for measuring ambient temperature ( T _amb ) and a sky-directed ambient temperature sensor for at least partially An onboard infrared sensor that measures the sky temperature ( T _sky ) based on the infrared radiation received in the field of view. Two or more IR sensor devices may be used, eg, to provide redundancy and/or improve accuracy. In one condition, at least one (eg, each) infrared sensor device outputs readings of ambient temperature ( T _amb ) and sky temperature ( T _sky ). In another condition, at least one (eg, each) infrared sensor device outputs the ambient temperature ( T _amb ), the sky temperature ( T _sky ), and the difference between T _sky and _Tamb (difference Δ) reading. In one condition, at least one (eg, each) infrared sensor device outputs a reading of the difference between T _sky and _Tamb (difference Δ). According to one embodiment, the logic of module D uses raw sensor readings of measurements taken by two IR sensor devices at the building. In some embodiments, the logic of module D uses a raw source of measurements taken by at least 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10 IR sensor devices at the building Sensor readings.

In another implementation, module D 2712 receives and uses raw sky temperature ( T _sky ) readings taken by infrared sensors at the building and ambient temperature readings ( T _weather ) from weather feeds, which The sensor is directed to the sky to receive infrared radiation within its field of view. Weather feed data may be received from one or more weather services and/or other data sources via a communication network. Weather feed data may include other environmental data associated with weather conditions such as percent cloud cover, visibility data, wind speed data, percent chance of precipitation, and/or humidity. Weather feed data may be received (in signal) by the window controller via the communication network. The window controller may send a signal with a request for weather feed data to one or more weather services over the communication network via the communication interface. The request may include at least the longitude and latitude of the location of the window being controlled. In response, one or more weather services may send a signal with weather feed data to the window controller, eg, via a communications network (eg, and via a communications interface). Communication interfaces and networks can be wired and/or wireless. In some cases, weather services may be accessed via a weather website. An example of a weather website can be found at www.forecast.io. Another example is the National Weather Service (www.weather.gov). Weather feeds may be based, at least in part, on the current time, or may be forecast at future times. Weather feeds may be based at least in part on geographic locations (eg, on enclosures and/or windows). An example of a logic using weather feed data can be found in International Patent Application No. PCT/US16/41344, filed July 7, 2016 and entitled "CONTROL METHOD FOR TINTABLE WINDOWS" , this application is hereby incorporated by reference in its entirety.

In one embodiment, based at least in part on (i) sky temperature readings from one or more infrared sensors, (ii) from one or more local ambient temperature sensors, and/or from weather feeds The temperature value ( T _calc ) is calculated from the ambient temperature reading and/or (ii) the cloudy offset value. In some embodiments, the cloudy offset value corresponds to the temperature offset of the first and second threshold values used in module D 2712 to determine cloud conditions. In one embodiment, the cloudy offset value is -17 millidegrees Celsius. In one example, a cloudy offset value of -17 millidegrees Celsius corresponds to a first threshold value of 0 millidegrees Celsius. In one embodiment, the cloudy offset value is in the range of -30 millidegrees Celsius to 0 millidegrees Celsius.

In one embodiment, a temperature value ( T _calc ) may be calculated based at least in part on sky temperature readings from two or more pairs of thermal sensors, at least one (eg, each pair) of thermal sensors With infrared sensor and ambient temperature sensor. In one case, the thermal sensor in at least one pair (eg, each pair) is an integral component of the IR sensor device. At least one (eg, each) IR sensor device may have an onboard infrared sensor and/or an onboard ambient temperature sensor. Two IR sensor devices may be used, eg, to provide redundancy and/or improve accuracy. In another situation, the infrared sensor and the ambient temperature sensor are located separately (eg, in separate devices and/or separate locations). In this embodiment, the temperature value is calculated as: T _calc = minimum ( T _sky1 , T _{sky2 ,} ...) - minimum ( T _amb1 , T _amb2 , ...) - cloud offset ( equation 1 ) T _sky1 , T _sky2 . . . are temperature readings obtained by a plurality of infrared sensors, and _Tamb1 , _Tamb2 . . . are temperature readings obtained by a plurality of ambient temperature sensors. If two infrared sensors and two ambient temperature sensors are used, then T _calc = minimum ( T _sky1 , T _sky2 ) - minimum ( T _amb1 , T _amb2 ) - cloud offset. The minimum value of readings from multiple sensors of the same type is used to bias the results towards lower temperature values that would indicate higher cloud cover and may result in higher hue levels in order to bias the results to reduce (eg, avoid) glare .

In another implementation, module D 2712 can switch from using the local ambient temperature sensor to using weather feed data, such as when ambient temperature sensor readings become unavailable or inaccurate, such as where The ambient temperature sensor is reading heat radiated from a local source such as a roof and/or a nearby radiant (eg, heating) source. In this embodiment, the temperature value ( _Tcalc ) is calculated using the sky temperature reading and the ambient temperature reading ( _Tweather ) from the weather feed. In this embodiment, the temperature value is calculated as: T _calc = minimum ( T _sky1 , T _{sky2 ,} ...) - T _weather - cloud offset ( Equation 2 )

In another embodiment, the temperature value ( T _calc ) is calculated using a reading of the difference Δ between the sky temperature and the ambient temperature as measured by two or more IR sensor devices, at least one ( For example, each sensor device has an onboard infrared sensor and an ambient temperature sensor. In this embodiment, the temperature values are calculated as: T _calc = minimum ( Δ ₁ , Δ ₂ ,...) - cloud offset ( eq . 3 ) Δ ₁ , Δ ₂ . . . are sensed by multiple IRs A reading of the difference Δ between the sky temperature measured by the device and the ambient temperature. In implementations using Equation 1 , Equation 2 , and Equation 3 , the control logic uses the difference between the sky temperature and the ambient temperature to determine the IR sensor value input to module D 2712 to determine cloud conditions . Ambient temperature readings tend to fluctuate less than sky temperature readings. By using the difference between the sky temperature and the ambient temperature as input to determine the hue state, the hue state determined over time may fluctuate to a lesser extent.

In another embodiment, the control logic uses sky temperature readings from two or more infrared sensors to calculate _Tcalc . In this implementation, the IR sensor values determined by module D 2712 utilize sky temperature readings (eg, and are not based on ambient temperature readings). In this case, module D uses sky temperature readings to determine cloud conditions. Although the implementations described above for determining T _calc are based on two or more (eg, redundant) sensors of each type, it should be understood that the control logic may utilize data from a single sensor read to implement.

In one embodiment, module B 2710 provides weather forecasts using sub-module 2710a with logic that uses machine learning (eg, including deep learning) on the time series of weather data provided by modules C and D . Submodule 2710a includes recursive artificial intelligence (eg, neural network) model logic to implement long short-term memory (LSTM) to map sequence-to-sequence (eg, using a seq2seq encoder/decoder framework) predictions. Using LSTM seq2seq forecasts or other LSTM forecasts, user-defined durations of historical weather data (e.g., 3-minute memory, 5-minute memory, etc.) can be used to generate short-term forecasts of user-defined length on a real-time rolling basis (e.g., , next 4 minutes), for example when getting new sensor values from modules C and D. This parameter flexibility increases the likelihood of retaining memory for changing weather conditions only at the scale available for the forecast window of interest.

In one embodiment, artificial intelligence module LSTM (eg, seq2seq) prediction is implemented such that it utilizes discretization of sensor values from modules C and D into (eg, three) distinct ranges and corresponding hue suggestions ( For example, shades 2, 3 and 4). The level of accuracy required for the weather forecast can be defined by a timely correspondence to an appropriate range of sensor values, such as when real-time data changes. This level of accuracy may allow for periods of greater variability (eg, sudden changes in conditions) to be handled using forecast smoothing and other regularization control structures designed to limit over-response model behavior. In one embodiment, an implementation of artificial intelligence LSTM (eg, seq2seq) prediction uses (i) a rolling mean of the largest light sensor readings over a time span of about 5 minutes and a rolling median of the smallest IR sensor readings, and (ii) Average a series of four (4) forecasts at T+4 minutes to produce a representative measure of the immediate future. Within the constraints defined by the existing time span (eg, 5 minutes) window control system command loop, this implementation supports the introduction of additional control structures, eg to increase the likelihood that command changes can be made within the time frame that existing hardware can respond to properties (for example, ignore command changes that last less than a user-defined number of minutes).

In one embodiment, the LSTM sub-module 2710a of module B 2710 processes the outputs from module C 2711 and module D 2712 as univariate inputs according to an LSTM (eg, seq2seq) method, eg, one of the univariate variables corresponds to At the maximum light sensor value provided by module C, and another univariate input corresponds to the minimum IR sensor value provided by module D. Processing at least one (eg, each) input according to an LSTM (eg, seq2seq) method may provide a ground truth value that is post-processed and normalized by a post-processing module 2714 to provide an output value mapped to a hue value. In some embodiments, it has been found that using an LSTM (eg, seq2seq) method is more suitable for providing relatively short-term predictions than for providing longer-term predictions.

In some embodiments, to obtain relatively longer-term weather forecast predictions based at least in part on the values provided by modules C and D, module B 2710 includes a sub-module 2170b having logic implemented including a deep neural network (DNN) Artificial Intelligence Methods for Multivariate Forecasting. In one embodiment, the DNN method characterizes engineering relationships between light sensor values and IR sensor values provided by modules C and D, which relationships can be used to predict occurrences over longer time horizons Weather and/or environmental conditions. Where the LSTM method outputs real-valued predictions (mapped onto their corresponding suggested tonal regions), the DNN predictions can be implemented as binary classifiers whose log-likelihood outputs probabilistically model sunny versus non-sunny conditions. Using binary classification may require flexibility in determining (optimization, location specification, and user personalization) a confidence threshold value (between zero and one) above which the model predicts sunny days (rather than non-sunny) conditions. Lower confidence thresholds may be set to proactively reduce (eg, prevent) high risk glare conditions. To maximize internal natural light, a higher confidence threshold can be set. In one embodiment, the DNN output is based, at least in part, on a user configurable threshold value, wherein an output greater than or equal to the threshold value is considered a sunny condition (eg, a binary value of 1) and/or wherein an output below The output of the threshold value is treated as a non-sunny condition (eg, a binary value of 0).

In some embodiments, the artificial intelligence (eg, DNN and LSTM) models reside on servers and/or window controllers on a cloud network, such as the main window controller or window of a distributed network of window controllers Controller group. Various commercially available machine learning frameworks can reside on cloud servers and/or control systems (eg, window controllers) to define, train, and execute artificial intelligence (eg, DNN and/or LSTM) models. An example of a commercially available machine learning framework is TensorFlow® provided by Google® of California. An example of a commercially available machine learning (eg, artificial intelligence) framework is Amazon® SageMaker® provided by Amazon Web Services of Seattle, Washington.

In one embodiment, the DNN submodule 2170b uses a DNN binary classifier that generates an 8-minute weather forecast using a 6-minute history. Unlike univariate LSTM predictions, DNN binary classifiers may not need to run on-the-fly, easing the computational load on existing hardware. To account for site-specific differences (on top of geographic location, seasonal changes, and continuously changing weather peaks), a DNN binary classifier can be run overnight using two to three weeks of historical data updated daily, discarding the oldest day and Introduce recent data when retraining the model at least one (eg, every) night. Such rolling daily updates increase the likelihood that the classifier will keep pace with the pace and qualitative nature of changing weather conditions. After retraining, model parameter weights may be adjusted to receive new input for generating forecasts for the duration of the second day.

In some embodiments, machine learning modules (eg, multivariate DNN and univariate LSTM) prediction submodules 2710a , 2710b together provide foresight in anticipating and/or responding to changes in the (eg, external) environment. In one embodiment, to mitigate the potential effects of long-term under-responsiveness of DNNs and short-term over-responsiveness of LSTMs, module B 2710 is configured to provide outputs based, at least in part, on rule-based decisions made by voting logic 2786 . For example, if the LSTM output for the photo sensor (PS) maps to hue state 3 (ie, the sun is present), and the LSTM output for the infrared (IR) maps to hue state 3 (ie, the sun is present), and the DNN output provides a binary output of "0" (where "0" indicates a "cloudy" forecast and "1" indicates a "sunny" forecast), then most LSTM(PS), LSTM(IR) and DNN (PS and IR) ) is used as a forecast that environmental conditions will be sunny at future times. Consistency of the two of LSTM (PS), LSTM (IR) and DNN (PS and IR) may be the rules upon which the output to the window controller 2720 is provided. Most of the above should not be considered limiting, as in other embodiments, other majorities and minorities provided by LSTM (PS), LSTM (IR) and DNN (PS and IR) may be used to provide forecasts.

In one embodiment, future forecasts of weather conditions made by module B 2710 are compared by window controller 2720 to the hue rules provided by module A 2701 and, for example, if the output of module B 2710 is provided at a future time is an indication that the weather conditions will be sunny, then before that future time, the control system 2720 provides hue commands according to the hue rules provided by the module A 2701 . In another embodiment, and vice versa, if the output of module B 2710 provides an indication that the weather conditions in the future will not be sunny, then the control system 2720 provides a clear sky mode overriding by module A 2701 before the future time The hue command of the hue command of the group determination.

Returning to Figure 24 , in one embodiment, the window controller 2600 includes control logic that, at operation 2630 , determines whether an override exists to allow various types of overrides to separate the logic. If there is an overwrite, control logic at operation 2640 sets the final tone level of the partition to the overwrite value. For example, an override can be entered by inputting the current space occupant who wants to override the control system and set the tint level. Another example override is a high demand (or peak load) override, which may be associated with utility requirements to reduce energy consumption in a building. For example, on certain hot days in a metropolitan area, it may be necessary to reduce the energy consumption of the entire urban area so as not to overburden the urban area's energy generation and delivery systems. In such situations, building management can override the tint levels from the control logic to ensure that all tintable windows have high tint levels. This override overrides the user's manual override. Overriding values can have priority.

At operation 2650 , control logic may determine whether a hue level has previously been determined for at least one (eg, each) partition of the building being determined. If not, the control logic may iterate to determine the final tone level for the next partition. In some embodiments, if the determination of the hue state of the final partition is complete, then at operation 2660 a control signal for implementing the hue level of at least one (eg, each) partition is transmitted over the network to the tintable with the partition The power supply of the window device is in electrical communication to transition to the final tint level, and the control logic may iterate for the next time interval, returning to operation 2610 . For example, the tint level may be communicated via a network to a power supply in electrical communication with the electrochromic device of one or more electrochromic windows to transition the windows to the tint level. In some embodiments, the transfer of the hue level to the windows of the building may be implemented with efficiency in mind. For example, an instruction with an updated hue level may not be transmitted if the recalculation of the hue level indicates that there is no need to change hue from the current hue level. As another example, control logic may recalculate tonal levels more frequently for partitions with smaller windows than for partitions with larger windows.

In some embodiments, the control logic in FIG. 24 implements a control method for controlling all electrical power for the entire building on a single device (eg, on a single (eg, main or window) controller) The tint level of the chromatic window. Such a device may perform calculations for at least one (eg, all) electrochromic windows in a building, and/or provide an interface for transferring tint levels to, eg, electrochromic devices in individual electrochromic windows. There may be some adaptive components of the control logic of an embodiment. For example, the control logic can determine how an end user (eg, an occupant) attempts to override an algorithm at a particular time of day, and use this information in a (eg, more) predictive manner, eg, to determine desired hue levels . For example, an end user may be using a wall switch to overwrite a hue level provided by the control logic at a certain time in a sequence of consecutive days (eg, each day) to an overridden value. The control logic can receive information about these conditions and change the control logic to introduce an override value that changes the hue level to the override value from the end user at that time of day.

Referring back to FIG. 25 , in one embodiment, the window control system 2700 includes a module E 2713 having control logic configured to provide data that exists at a location based at least in part on past (eg, history) data Statistically informed predictions of site-specific and/or seasonally differentiated profiles of light and heat radiation. In one embodiment, the location-specific values provided by module C 2711 and module D 2712 are stored in memory as time series data by the window control system 2700 , and the profile is generated by module E 2713 according to the time series data . The ability to use past data (also referred to herein as "historical data" or "historical data") obtained at the particular location for which a forecast is requested may enable more accurate forecasts. In one embodiment, constructing such equivalence curves involves the use of machine learning (eg, artificial intelligence) classification algorithms suitable for clustering time series information into longitudinal sensor values exhibiting similar shapes and/or patterns such a group. Depending on the level of granularity requested (for a given hour of the day, time of day, week, month, and/or season of the year), the identified cluster centroids may show the mean of all records within that time range trajectories, the similarity between the records themselves can be quantitatively distinguished from other groups of similar records. Such distinctions between groups may allow for statistical inference relative to "typical" environmental conditions for which monitoring at a given site is requested during the time frame.

The algorithmic classification of discrete weather profiles begins in an unsupervised manner without having ground truth knowledge deemed "typical" for a given location and time frame. Since the "correct" class cannot be predefined, evaluating the performance of a classifier may require inferential decisions about how many outputs can take action, such as the number of distinct clusters that can actually be used for differentiation.

In Figure 25 , a univariate input of the requested length and/or granularity (eg, from Module C and/or Module D) is passed to Module E 2713 , which is configured to perform unsupervised learning The function of the classifier. If the problem of interest consists of profiling daytime weather patterns at a given location within a month, then preprocessing by module E 2713 produces an m × n dimensional data frame, where m is the number of daylight minutes and n is the collected The number of days for the light sensor input. Since different latitudes correspond to different solar trajectories during different seasons, different sensors (eg, pointing in different directions) may be important at different times of the day and/or seasons. Incorporating such differences may involve performing data reduction techniques (eg, principal component analysis) to compress the time series information from the x number of sensors into a one-dimensional vector captured from at least one (eg, each) The y strongest radiation signals received in the main direction. Since the number of data points for sunlight will vary from day to day, the data input of preprocessing module E 2713 also involves the alignment of time indices. Similarity between individual time series vectors (eg, cluster candidates) can be measured as a function of point-wise (Euclidean) distance. Misalignment of the time indices can lead to distorted distance calculations, thereby distorting the clustering procedure.

One method for dealing with misalignment caused by differences in vector lengths may involve dividing the original time series into equally sized frames, and computing the mean of at least one (eg, each) frame. This transformation approximates the longitudinal shape of the time series on a piecewise basis. The data dimension can be reduced or expanded so that clustering distance computations can be performed unquestionably for a number n of time series of equal length.

The alignment handler provided by module E 2713 can be configured to perform dynamic time warping (DTW) methods. The DTW method stretches or compresses the time series by constructing a warp matrix from which the logic searches for the best warp path that minimizes data distortion during realignment. This handler increases the likelihood that the distance calculation performed by the clustered classifier does not find two sequences that are "farther" apart (only slightly different in frequency) than they actually are. Performing pointwise distance calculations across thousands of records is computationally expensive. The DTW method can be accelerated by enforcing locality constraints or window constraints (eg, a threshold window size) beyond which the DTW method does not search when determining the best twist path. The mapping within this threshold window size can be considered when calculating the pointwise distance, thereby (eg, substantially) reducing the complexity of the operation. Other locality constraints (eg, LB-Keogh bounds) can be applied, eg, to reduce (eg, the vast majority) of DTW operations.

After preprocessing by module E 2713 , the data frame of the time series vector can be input to the unsupervised learning logic. Since the appropriate number of clusters ( k ) can vary by location, season, and other unquantified factors, the use of K-means clustering logic can be identified as a suitable method to be used by module E 2713 . The use of K-means clustering logic may allow the user to define, hand-tune and/or fine-tune the number of identified clusters to increase the output that is not only broadly representative, but also interpretable, actionable and/or actually useful possibility. Maintaining the mxn - dimensional data frame example mentioned above, performing the K-means clustering logic can randomly select the number k days from the number n time series vectors as the number of k candidate clusters The initial centroid to start with. A locality constraint is imposed before computing the pointwise DTW distance between at least one (eg, each) centroid and all other time series vectors in the data frame. A vector can be assigned to the closest (most similar) centroid, which is then recalculated as the mean of all vectors assigned to the same group. This procedure may be repeated (I) a user-defined or other predefined number of iterations, or (II) until other iterations no longer result in reassignment of vectors to different clusters. In some embodiments, at the end of the process, the classifier of module E 2713 will have clustered the data into k groups of vectors exhibiting a similar pattern of longitudinal sensor values formed in Specifies the k most representative profiles of sensor data collected in the past time range. The more historical data are used to construct these profiles, the more representative and informative these K-means groupings can be.

The profiles determined by module E 2713 can be used to generate information about the previous distribution of radiation levels occurring within a given range within a given time range at a given geographic location. Under the Bayesian principle assumption that these "typical" profiles identified constitute a mixture of Gaussian (eg, stochastic normal) procedures, we can rely on the first (mean) and third Two (variance) moments to quantify the certainty of predicted sensor values occurring within a specified range. Supervised kernel-based models (such as Gaussian Process Regression) can utilize the profiles identified by unsupervised clustering to produce a full posterior distribution for one's predictions (e.g., for the predicted sense). Confidence Intervals for Detector Values) to gain insight into likely (variance) and most likely (mean) end results. Thus, in one embodiment, unsupervised machine learning techniques of one module (eg, module E 2713 ) may be paired with supervised machine techniques of another model (eg, module B 2710 ), eg, to enhance and/or Or improve weather forecasts (for example, by mod B 2710 ). In one embodiment, the probability confidence obtained using the DNN submodule 2710b uses the profiles provided by module E 2713 to modify and/or better quantify its predictions. In some cases, at least one module may not function correctly, during which time (eg, and until the failure is identified and corrected), the control system (eg, 2700 ) may not be able to provide its intended functionality. Between travel costs, materials used, maintenance services provided, and/or system downtime affecting customers; the cost of processing this event may accrue. One type of failure that may occur is when one or more sensors associated with one or more modules (eg, modules C and/or D) fail. Although one or more sensors may not provide their intended functionality, the present invention may identify that location-specific sensor data (eg, stored by the control system (eg, 2700 )) as time series data that The data may, for example, be used for purposes other than those described herein.

In one embodiment, if functionality associated with one or more modules (eg, module C 2711 and/or module D 2712 ) fails or becomes unavailable, the present invention identifies that the configured Modules (eg, 2719 ) with control logic to perform weighted barycenter averaging may be applied to historical sequences of sensor data (eg, obtained in the past) to provide, for example, sensor value distributions, etc. Sensor values may be used as a substitute for current readings and/or to provide forecasts of future weather conditions. In one embodiment, the surrogate readings may be processed by a neural network (eg, by module B). In one embodiment, days that are closer to the present may be given a correspondingly greater weight when averaging day-long-series sensor data across a rolling window of the most recent past. In the event of a hardware failure, a weighted center-of-gravity average of historical sensor data may be supplied for the duration of any downtime (eg, required for repair or maintenance).

In some embodiments, computing the weighted centroid mean involves preprocessing and/or machine learning, such as to align the coordinates in time and/or minimize the distance between time series profiles used in generating the optimal set of means, The set of optimal means reflects the requirements of the weighting scheme. In one embodiment, a suitable preprocessing technique is piecewise aggregate approximation (PAA), which works by dividing a time series into a number of segments equal to the desired number of time steps, and then replacing at least one ( For example, each) segment to compress the data along the time axis. After applying PAA, all time series profiles included in the historical rolling window may contain an equal number of time steps (eg, regardless of seasonal differences in day length), which may vary within a specified time frame. Equal dimensions along the time axis may be required to compute the pointwise distance minimized by the optimization function used to perform centroid averaging. While a range of different distance measures can be used to compute the center of gravity, other solutions such as Euclidean or soft dynamic time warping (soft DTW) measures can be used to provide mean profiles. In some embodiments, the former is faster and performs a general straight-line distance between coordinates along the time axis, while the latter is a regularized, smoothed formulation of the DTW metric that applies a bounding window to its distance calculation, such as with Consider (eg, slightly) the phase difference. Constraints can be imposed on the centroid optimization function to determine the length of the rolling window of historical data to be used. A time frame with a high optimization cost may indicate changing weather. A time horizon with a high optimization cost guarantees that centroid averaging is performed using a short rolling window of several days. Lower optimization costs may correspond to more stable weather, and longer rolling windows from which informative historical data can be obtained when performing centroid averaging. In one embodiment, centroid averaging can be generated on a site-specific basis using any available historical data.

In some embodiments, when real-time data becomes (or is) unavailable, a centroid averaging operation (eg, in module 2719 or in module 2819 ) may be implemented to generate a synthetic real-time pristine feel from historical data tester data. For example, if a sensor device (eg, a multi-sensor device or a sky sensor at a location) fails or otherwise becomes unavailable, a centroid averaging operation can be used to generate a composite real-time sensor (eg, light sensor and/or infrared sensor) readings. To generate synthetic sensor data that emulates real-time raw sensor data, centroid averaging may use historical sensor data stored over a time frame to calculate at least one (eg, each) time index (eg, since sunrise). Point-by-point weighted distance to sunset), resulting in a possible radiation profile for the second day. In one example, historical sensor data over a time frame in the range of 7 to 10 days may be used. Center of gravity averaging may use the same distance between time indices over at least two days (eg, daily) of the time range, eg, at intervals of at least about 0.5 minutes (min), 1 minute, 1.5 minutes, 2 minutes, or 3 minutes . The number of time indices may vary depending on the day lengths of the respective days between sunrise and sunset. In some embodiments, the number of time indices in at least two consecutive days expands or contracts to account for seasonal changes in daylight minutes as days get longer or shorter. In some embodiments, centroid averaging is used to calculate a weighted average of historical sensor values for at least two time indices (eg, each time index) within a time range, with more recent values weighted more heavily. For example, centroid averaging may use stored historical light sensor readings taken at 12:00 noon each day over a 10-day time frame, with greater weighting of readings from recent days (eg, day 10 The weight is 10 for the 9th day, 8 for the 8th day, etc.) to calculate the weighted average of the light sensor values at 12:00 noon. Centroid averaging may be used to determine a weighted average of sensor (eg, light sensor) values for at least two time indices (eg, at each time index), resulting in a composite real-time light sensing within a day mean profile of the device values.

The centroid averaging operation may be used to generate mean profiles of synthesized real-time sensor values (such as light sensor values, infrared sensor values, ambient temperature sensor values, etc.). The centroid averaging operation can use the synthesized real-time sensor values obtained from the mean profile to generate inputs for various modules and models that may need to be executed within a day. For example, a centroid averaging operation may use rolling history data to generate synthesized sensor (eg, light sensor) values as a neural network to, for example, the LSTM neural network of module 2710a and/or the DNN of module 2710b An input in a network model (or other model).

In some embodiments, the set of input features for at least one (eg, each) of the neural network models (or other models) is kept up-to-date and ready to be fed into a real-time model, eg, to predict locations conditions of the place. In some embodiments, the input feature is based at least in part on sensors from the location (eg, light sensor, infrared sensor, ambient temperature sensor, ultraviolet sensor, occupancy sensor etc.) (eg, raw) measurements. The sensor may be a sensor disclosed herein. The input characteristics may be based at least in part on (eg, raw) measurements of current and/or voltage. In certain embodiments, the sensors are located in a single housing or otherwise centrally located, for example, in a multi-sensor device such as a set of devices. A collection of devices can be housed in an enclosure (eg, a facility, building, or room), or outside the enclosure. For example, sensor sets may be located on roofs of buildings and/or in sky sensors. A multi-sensor device may include a plurality of sensors, such as at least about 2, 4, 6, 8, 10, or twelve (12) sensors. The sensor may include a light sensor. Sensors can be configured in a single column. A single row can be placed on an arc. A single row can be placed along the ring. The sensors may be positioned radially. The sensors can be placed in various azimuthal orientations. At least one sensor (eg, a light sensor) may be oriented vertically (facing upwards in a direction opposite the center of gravity when installed). The device may include at least one or two infrared sensors (eg, upwardly oriented). The device may include at least one or two ambient temperature sensors. The device may include a transparent housing portion (eg, glass, sapphire, or plastic). The device may include an opaque housing portion. The device may include a portion that is transparent to radiation sensed by a sensor disposed in the housing. The set may include redundancy of sensors. The set may include at least two sensors of the same type. The set may include at least two sensors of different types. An example of such a multi-sensor device that can be mounted to the roof of a building is described in an application entitled "Light Diffusing Elements with a Perimeter Surrounding a Ring of Light Sensors and Infrared Sensors," filed on Oct. 06, 2016. Multi-sensor device and system with a light diffusing element around a periphery of a ring of photosensors and an infrared sensor" U.S. Patent Application Serial No. 15/287,646 (now in January 2020) US Patent No. 10,533,892, issued March 14), which patent application is hereby incorporated by reference in its entirety. Information from multiple different sensors can be used in various ways. For example, at a particular time, measurements from two other sensors (eg, of the same type) can be combined, such as the central tendency, this mean or the average of the sensor values. At a particular time, only one measurement may be used; such as the maximum value from all sensors, the minimum value of all sensors, or the median value of all sensor readings in the set. In one embodiment, the model input features are based, at least in part, on maximum, minimum, and/or average values of a plurality of raw sensor readings (eg, mean or median). For example, the model input feature may be based at least in part on a maximum of multiple raw light sensor readings obtained by (eg, thirteen) light sensors of a multi-sensor device and/or at least in part on The minimum IR sensor value, eg, the minimum value of the two IR sensor readings is less than the minimum value of the two ambient temperature sensor readings of the multi-sensor device. The maximum light sensor value may represent the highest level of solar radiation at the location, and the minimum infrared sensor value may represent the highest level of clear sky at the location.

In some embodiments, the set of input features fed into the neural network model (or other model) includes the computation of multiple rolling windows of historical sensor data. In one case, a plurality (eg, six (6)) rolling windows ranging in length from about five (5) minutes to about ten (10) minutes are used. Examples of rolling calculations may include rolling mean, rolling median, rolling minimum, rolling maximum, rolling exponentially weighted moving average, and/or rolling correlation. In one embodiment, the input feature set includes rolling mean, rolling median, rolling minimum, rolling maximum, and rolling exponential weighting of multiple rolling windows of historical data of maximum light sensor value and minimum IR sensor value Rolling calculations (eg, six times) of moving averages and/or rolling correlations (eg, where forecast outputs are learned based on historical time horizons for these inputs). For example, if for each of the maximum light sensor and minimum IR sensor values, six (6) rolling calculations are used for a length ranging from six (6) minutes to five of ten (10) minutes ( 5) rolling windows, where the predicted output is learned from four (4) minutes of history, then the input feature set will be 240 (=6 rolling computations × 5 rolling windows × 2 sensor values × 4 minutes). The rolling window may be updated periodically (eg, every minute) to discard (eg, delete) the oldest data and bring in the most recent data (eg, update with the most recent data). In some cases, the length of the rolling window is chosen to minimize delays in queuing data during real-time (real-time) forecasting.

In certain embodiments, a machine learning submodule with self-correcting feature selection procedures such as those described herein may be implemented to (eg, indirectly) quantify and/or empirically verify the relative importance of all potential model inputs , thereby reducing the number of features in the input set to a more efficient input configuration. In such cases, the total number of input features can be reduced to a smaller subset that can be used to initialize and/or execute the model. For example, six (6) lengths ranging from about five (5) minutes to about ten (10) minutes may be based, at least in part, on both the raw maximum light sensor value and the minimum IR sensor value. The set of seventy-two (72) input features is reduced to a subset of 50 input features for six rolling calculations over a rolling window.

In one embodiment, the input features (eg, a set of two hundred (200) or more input features) are fed into the neural network. One example of a neural network architecture is a deep dense neural network, such as a network with at least seven (7) layers and at least fifty-five (55) total nodes. In some DNN architectures, at least one (eg, each) input feature is connected to at least one (eg, each) first layer node, and at least one (eg, each) node is connected to at least one (eg, each) node ) placeholder for other node connections (variable X). Nodes in the first layer model the relationship between all input features. A node in a subsequent layer learns one of the relationships modeled in at least one of the previous layers. When performing a DNN, the error can be iteratively minimized, eg, by updating the coefficient weights of at least one (eg, each) node placeholder.

In some cases, the model outputs one or more predicted condition values in the future. For example, the model may output forecasted conditions at some point in the future (eg, about five (5) minutes to about sixty (60) minutes in the future). In some embodiments, the model outputs forecasted conditions about seven (7) minutes in the future (t+7 minutes). As another example, the model may output forecasted conditions some time in the future, such as about seven (7) minutes in the future (t+7 minutes), about ten (10) minutes in the future, or about fifteen (15) minutes in the future (t+ 10 minutes). In other cases, the model outputs predicted sensor values, such as in a single DNN architecture embodiment.

Various neural network models (or other predictive models) may be retrained periodically to account for geographic location, seasonal variation, and location-specific differences in changing weather pre-peaks. In some embodiments, the network models are retrained daily or on some other periodic basis (eg, between every 1 and 10 days) with updated training data. The models may be retrained at a certain time, such as when the real-time model is not executing, such as during nighttime, vacation, holiday, other facility closures, or during any other low-occupancy time window. In certain embodiments, the models are retrained using training data, including historical data stored over a period of time, such as at least about one week, two weeks, three weeks, or more. Historical data may be updated in a timely (eg, periodically) manner, eg, according to a schedule. Historical data may be updated to discard (eg, delete and/or archive) the oldest data and bring in the most recent data (eg, update with the most recent data). For example, in the case where historical data is updated daily at night, the data from the earliest day is discarded and the latest data from that day is inserted. Such periodic updates increase the likelihood (eg, ensure) that historical data is consistent with the pace and/or qualitative nature of changing external weather conditions such as temperature, sun angle and/or cloud cover. In some embodiments, the model is retrained using training data based at least in part on storing one or more blocks of historical data over multiple time periods. In some embodiments, the model is retrained using training data based at least in part on a combination of historical data and blocks of historical data. The training data may include characteristic input values of the type used by the model as input during normal and/or routine execution. For example, as described herein, the characteristic input data may include a rolling average of sensor readings.

In some embodiments, the training data includes values of model features based at least in part on historical data (rolled or otherwise) collected at the location. For example, training data may include maximum light sensor values and/or minimum IR sensor values for historical readings of light sensors and IR sensors at a location (eg, at an enclosure). In another example, the training data may include a rolling window (eg, rolling mean, rolling median, rolling minimum, Model characteristics for the calculation of rolling maximums, rolling exponentially weighted moving averages, rolling correlations, etc.). Depending on the number and type of weather conditions covered by the training data, the training data may include data obtained over days, weeks, months or years.

In some embodiments, the training data fed into the neural network model or other model includes model input features based at least in part on a plurality of historical sensor data such as those described above Calculation of rolling windows. For example, the training data set may include rolling mean, rolling median, Six rolling calculations of rolling minimum, rolling maximum, rolling exponentially weighted moving average, and rolling correlation, where the predicted output is learned based on the historical time horizon of these inputs. If for at least one (eg, each) of the maximum light sensor and minimum IR sensor values, six (6) rolling calculations are used for lengths ranging from six (6) minutes to ten (10) minutes Five (5) rolling windows, in which the predicted output is learned based on four (4) minutes of history, the input feature set in the training data will be 240.

In some embodiments, a neural network model (or other model) is retrained using training data based, at least in part, on blocks of historical data collected during one or more periods of the existence of various weather conditions at the period location to The model is optimized for these conditions and the training data is diversified over a subset of the entire domain. For example, training data may include values of model features collected over time periods during which partially cloudy conditions, Tule fog conditions, clear sky conditions, and other weather conditions exist at the location.

In some cases, the training data is designed with model features to capture one or more (eg, all) possible weather conditions at the location. For example, training data may include (eg, all) rolling historical data collected over the past year, the past two years, and so on. In another example, the training data may include blocks of historical data obtained over time periods during which individual weather conditions exist at the location. For example, training data may include one data set with data obtained during Thule fog conditions, one data set with data obtained during clear sky conditions, one data set with data obtained during 20% partial cloud conditions datasets, one dataset with data obtained during 60% partially cloudy conditions, etc.

In some cases, the training data is designed to have model features associated with a subset of one or more (eg, all) possible weather conditions at the location. For example, training data may include blocks of historical data obtained over time periods during which a subset of weather conditions occurred at a location. In this case, the model is optimized for a subset of weather conditions. For example, training data for a model optimized for Thule fog conditions may use input features obtained during the winter months and further during periods when Thule fog is present.

As weather patterns change and/or construction occurs around the site, microclimate changes, building shading, and other local changes in conditions may occur at the site. To accommodate changing conditions, training data can be designed with input features for data obtained when these local conditions exist at a location. In one embodiment, transfer learning may be implemented to initialize a model retrained with model parameters from a model previously trained for all pre-existing weather conditions at the location. The model may then be retrained using training data obtained during the new local conditions, eg, to increase the probability (eg, to ensure) that the model remains consistent with the qualitative properties of the changed local conditions at the location.

In some embodiments, the model being retrained is first initialized with model parameters (eg, coefficient weights, biases, etc.) that are based at least in part on hyperparameters; eg, based at least in part on a random distribution of the data. Various techniques can be used to determine a random distribution, such as using a truncated normal distribution.

During model training, the model parameters (eg, coefficient weights, biases, etc.) can be adjusted and the error can be iteratively minimized until convergence. A neural network model (or other model) can be trained to set the model parameters that will be used in the live model the next day. The real-time model being executed may use input features based at least in part on real-time sensor values, such as to predict conditions that will be used by control logic to make hue decisions (eg, during that day and/or in real time). Model parameters learned during the retraining procedure can be stored and/or used as a starting point in the transfer learning procedure.

In some embodiments, the transfer learning operation uses the stored model parameters learned in the previous training procedure as a starting point to retrain the new model. For example, a transfer learning operation may initialize one or more new models using the coefficient weights of the node placeholders of a previously trained neural network model. In this example, the coefficient weights for the node placeholders of the trained model are saved to memory and reloaded to initialize a new model such as daily retraining. Initializing the new model with the model parameters of the pretrained model may facilitate and/or speed up the convergence to the final optimized model parameters, and/or speed up the retraining process. Transfer learning eliminates the need to retrain a new model from scratch (with random initialization). For example, during the daily retraining procedure, the model may be initialized with the coefficient weights of the node placeholders of the previously trained model. Model training can be characterized by fine-tuning coefficient weights and modifying job parameterizations. By starting with the coefficient weights of the previously trained model, the optimization of the coefficient weights starts closer to the global error minimum. This training may reduce the number of coefficient weight updates and/or iterations during optimization, which may help reduce platform downtime and/or computing resources. For certain layers and/or nodes, the transfer learning operation may fix the transferred model parameters in the new model. Transfer learning operations may only retrain unpinned layers and/or nodes, which may reduce computing resources and/or platform downtime.

In some embodiments, transfer learning operations are included in the retraining process of the model. At least one (eg, each) of the retrained models may be initialized with stored model parameters from a previous training procedure. In one embodiment, transfer learning operations are included in daily retraining of the model that may need to be performed within a day. For example, transfer learning operations may be included in retraining operation 2903 of Figure 27A . In these embodiments, transferring knowledge acquired during initialization and daily retraining facilitates finer-grained adjustments to location-specific changes in conditions.

In one embodiment, the transfer learning operation initializes the model with stored model parameters from a previous training procedure using training data from blocks of historical data within a first time period. For example, the previous training procedure may use blocks of historical data over time periods of at least one (1) month, two (2) months, three (3) months, or more than three months. During retraining of the initialized model, the model may be retrained to update the model, eg, using training data based at least in part on rolling historical data over a second time period. For example, the retraining procedure may use a rolling window with a second time period ranging from about five (5) days to about ten (10) days. The time period of the historical data block is longer than the time period of the rolling window.

In one embodiment, the transfer learning operation initializes the model with stored model parameters from a previous training program using data from a first time period (eg, at least about one (1) month, two (2) month, three (3) months or more) of training data for historical data blocks. During retraining of the initialized model, the initialized model may be retrained using training data based at least in part on a target subset of weather conditions to update the initialized model. For example, training data may include data obtained under new weather conditions during a second time period, such as during a two-week period of three months prior to retraining. The retraining procedure may use the training data to retrain the model during the second time period.

In certain embodiments, the real-time model selection framework facilitates the release of specialized models, such as optimized to work with (eg, only) light sensor inputs, (eg, only) infrared sensor inputs, (eg, only) These models are used with weather feeds, etc. In these and other embodiments, the control logic executes a subset of the full set of modules and models illustrated in FIG. 25 . The unexecuted portion may be stored in memory and retrained for execution at a future day, or may not exist in the architecture.

The control logic may execute one or more models (eg, selectively). For example, in one embodiment, the control logic illustrated in FIG. 25 does not implement modules B and E, and instead implements module C 2711 , module D 2712 , and center of gravity averaging module 2719 . In this embodiment, the recurrent LSTM neural network of module 2710a is not implemented, and a single deep neural network (DNN) is instead implemented. According to one aspect, a single DNN is a sparse DNN with a reduced number of model parameters from the total number of model parameters in the DNN of module 2710b that will be used to implement the complete set of models and modules. In one example, the sparse DNN has 20% of the model features of the DNN of module 2710b . In one embodiment, a linear kernel support vector machine (SVM) or other similar technique is performed to eliminate the model features of the sparse DNN to a subset of the total number of potential features of the DNN of module 2710b .

26 is an example of a block diagram of a window control system 2800 with a single DNN architecture, according to an embodiment. The window control system 2800 includes a window controller 2820 , such as a master controller or a local window controller. The window control system 2800 includes control logic depicted by certain blocks. One or more components of window control system 2800 implement control logic. The control logic includes a center of gravity averaging module 2819 , a DNN module 2830 , a module A 2801 , a module C1 2811 and a module D1 2812 . In one case, the DNN module 2830 includes a sparse DNN. Module A 2801 includes logic similar to module 2701 of FIG. 25 .

The center of gravity averaging module 2819 can be executed to determine a composite real-time sensor value based at least in part on historical sensor data and/or to determine an average sensor for a day based at least in part on the composite real-time sensor value profile. For example, the center of gravity averaging module 2819 may be executed to determine the average photo sensor profile and/or the average infrared sensor profile within a day. In one case, the center of gravity averaging module 2819 may be implemented to (eg, additionally) determine the average ambient temperature sensor profile for a day. The centroid averaging module 2819 may use rolling history data to generate composite values as input to the DNN module 2830 . The real-time sparse DNN of DNN module 2830 may use input features based at least in part on synthesized values from centroid averaging module 2819 to output one or more predicted IR sensor values for use as input to module D1 2812 and One or more predicted light sensor values for use as input to module C1 2811 are output. For example, the DNN module 2830 may output predicted IR sensor values and predicted photo sensor (PS) values for a time at least about 7 minutes in the future, about 10 minutes in the future, or about 15 minutes in the future, etc.

In some embodiments, module C1 2811 includes control logic that can be executed to determine cloud coverage conditions by comparing photo sensor values and threshold values of real-time DNN output from DNN module 2830 to at least The hue level is determined based in part on the determined cloud cover conditions. Module D1 2812 may be executable to determine hue levels based at least in part on infrared sensor values and/or ambient temperature sensors output from real-time DNN 2830 . The window controller 2820 may execute the tint command based at least in part on the maximum value of tint levels output from module A 2801 , module C1 2811 , and module D1 2812 .

In some embodiments, the control logic configured to determine the window tint state dynamically selects and/or deploys a particular model from a suite of available models. At least one (eg, each) model may have a set of conditions. A model may have a set of conditions under which the model determines the window tint state better than at least one other model (eg, the other model) in the suite. The framework (or framework) used to implement this method may include logic for selecting models (eg, a suite of specialized models) trained to produce the best results under specific conditions for which the models are optimized change. The framework may provide for uninterrupted and/or real-time hue state decisions, eg, even when different models are deployed at different times.

In some embodiments, instead of deploying a single-purpose model to handle all possible external conditions that a building encounters throughout the day, week, season, or year; the model selection framework dynamically selects the model. The model selection logic may, for example, select a model at any time that is determined to most efficiently handle certain kinds of external conditions as they arise (eg, instantaneously), for example. For example, the selection may be based, at least in part, on the environmental conditions currently prevailing at a particular location (eg, at a building site) and/or at least in part on conditions expected during a future time of the year, time of day, etc.

In some embodiments, the model selection logic evaluates conditions and/or selects a model, eg, while one of the available models is executing (in real time). This means that the hue decision logic can be shifted between models, eg, without any (eg, significant) downtime. To this end, the control logic may (eg, continuously or intermittently) receive currently available data. Control logic can dynamically deploy models optimized for handling (eg, currently observed immediate and/or future) conditions. Such conditions may be external conditions (eg, temperature, sun angle, cloud cover, radiation, and/or any other weather conditions) external to the enclosure (eg, facility).

In some embodiments, a dynamic model selection framework is used to provide flexibility for the tone selection logic. In some embodiments, the model selection logic considers situations where one or more types of feature input data (for the model) become temporarily unavailable. For example, a first model may require multiple types of input features and at least one specific type of feature (eg, and IR sensing values), and a second model may require the same input feature but not at least one specific type of feature (eg, but IR sensed values are not required). If the hue decision logic is using the first model and the IR sensor suddenly becomes disabled (eg, offline), the model selection logic may then switch to the second model to continue making immediate hue decisions. In some cases, the model selection logic may consider situations where one or more of the models fails or otherwise becomes unavailable, and the logic must choose a different model (eg, immediately or after a minimum elapse of time).

In some embodiments, the real-time model selection framework facilitates the release of specialized models (such as those optimized for use with (eg, only) light sensor inputs), eg, allowing sensor units equipped with An earlier (or more) version of the building site realizes the benefits of model-driven prediction.

27A presents an example of a flowchart illustrating one method of dynamic model selection. The depicted procedure begins at operation 2901 , which may be associated with recurring events (such as the start of a new day, sunrise, etc.). The timing of such events need not be the same every day, and in some cases, need not even be based at least in part on repeating daily events. Regardless of the basis of the event, the program initializes or otherwise prepares the various available models for execution at operation 2903 . In the depicted embodiment, that operation involves retraining all models that may need to be performed for a day or other time period until the process begins again. The performance of the hue condition determination model may improve (eg, significantly) when the model is retrained frequently (eg, daily or even more frequently). At operation 2905 , the current conditions are provided to model selection logic. This can be done before, during, or after making all models ready to perform by retraining or other operations. Current conditions may be related to external weather conditions (eg, temperature, sun angle, cloud cover, radiation, etc.), which may be determined by one or more of the IR sensors and/or light sensors, such as those described herein. multiple sensors to determine. Alternatively, the current conditions may be based, at least in part, on a currently available set of input features (eg, weather data fed from the Internet, IR sensor data, light sensor data, etc.). Some models in the suite may not be available when only a subset of the available input features are available.

At operation 2907 , model selection logic selects a model for execution by considering current external conditions. For example, if current weather conditions indicate fog (or similar conditions), model selection logic may (eg, automatically) select trained and/or optimized for use in such (eg, foggy) conditions Models that accurately select tonal states. In another example, if the primary model requires multiple input features (eg, weather feed, IR sensor data, and light sensor data); and when the communication link fails (and the weather feed suddenly becomes unavailable ) when the primary model is executing, the model selection logic may (eg, automatically) trigger execution of a backup model that requires only a portion of the input features (eg, only IR sensor data and/or light sensor data) ) as input features.

In some embodiments, when the model selection logic identifies a model to execute based at least in part on current conditions, the logic should ensure continued seamless operation. To this end, logic may determine whether the model selected in operation 2907 is the currently executing model. See Decision Action 2909 . If so, it allows the currently executing model to continue executing and determines the future hue state. See operation 2913 . If not, it transitions to the newly selected model and is allowed to start determining future hue states. See operation 2911 .

Regardless of model switching or remaining constant, the program may loop through repeated checks of current conditions (eg, operation 2905 ) and selection of the best model for those conditions (eg, operation 2907 ) until window shading is no longer needed, such as At sunset or at the end of the day. See Decision Action 2915 . When an end event is determined by operation 2915 , program control leads to an end state 2917 , and no further model selection is performed until the next occurrence of a start event 2901 .

The hue decision logic may use an architecture having a plurality of models with a plurality of models that can be used to determine which hue state of the window best considers (eg, recent) weather conditions. The number of models available for selection may depend on a number of situation-specific factors, such as (i) the number of unique and/or potentially vulnerable sources of input features; (ii) the range of qualitatively different weather conditions in a particular location; and/ or (iii) available training and/or computing resources. In some embodiments, the number of models to choose from is at least three. In certain embodiments, the number of available models is from about two to about twenty, or from about three to about ten.

In some implementations, alternative (eg, all) models provide similar outputs, such as (i) hue decision and/or (ii) hue control logic may be used based at least in part on current (eg, weather, radiance, and/or) or sun position) conditions to determine what hue state to propose. For example, in some embodiments, at least one (eg, each) model is configured to output two or more possible (eg, discrete) hue states (eg, two, three, four) or more than four possible hue states). In some embodiments, at least one (eg, each) model is configured to output predicted radiation, glare conditions, heat flux, and/or other similar predictions (eg, as disclosed herein).

Alternative models may or may not require similar inputs. In situations where the model selection framework is intended to provide feature input redundancy, one or more of the models may require one set of feature inputs, while one or more other models may require a different set of feature inputs.

Models to choose from (eg, all models) can be of the same, similar, or unrelated model types. For example, all models may be structured at least in part on artificial neural networks having the same or similar architecture, eg, the networks may all be recurrent and/or convolutional neural networks having the same architecture. In some embodiments, some of the models have a first neural network architecture, while other models have a different neural network architecture. In some embodiments, one or the mobile model is a neural network, and the one or more other models may be regression models, random forest models, and/or other model architectures (eg, as disclosed herein). In some embodiments, some or all of these models are feedforward neural networks. In some embodiments, one or more of these models is a dense neural network.

In some embodiments, there are various scenarios in which real-time (eg, real-time and/or dynamic) model selection (eg, selection of the type of model used and/or underlying model architecture) is used in each scenario.

In some embodiments, the model is selected based on feature source elasticity. In this case, alternative models can be designed to work on different sets of input features. A given neural network may only function (eg, only) on a specified set of input feature types (eg, a particular model may require four inputs from an IR sensor and one input from a weather feed). A neural network may have a set of input nodes, at least one (eg, each) of which is dedicated to receiving (eg, only) one type of input feature. Additionally, models that require different sets of input features may be trained in different ways (eg, using different training sets) and may have different internal architectures. For example, if two hue prediction models use a neural network model architecture, their first layer may have (i) a different number of nodes (based at least in part on the expected number of distinct input features) and/or (ii) Nodes of different types. At least one (eg, each) available model may have an architecture and/or training method specific to its own set of expected input features.

In some embodiments, feature source resiliency is provided by using a model selection framework as described herein. In certain embodiments, feature source elasticity is provided by using a supplemental center of gravity averaging framework (or module) as described elsewhere herein. In some embodiments, centroid averaging is used to generate confidence intervals for data generated during real-time prediction when sensor data is available.

In some embodiments, the model is selected as an external condition specific model. In this case, alternative models can be designed and/or optimized for different types of external conditions. External conditions may include various weather conditions (eg, sunny, foggy, rapidly passing clouds, thunderstorms, smoke, area fires, and/or the like). In some embodiments, the model selection logic identifies the current type of external conditions from among various possible types of external conditions. The model selection logic may then select the model optimized to perform best under the current external conditions. In some embodiments, the characteristics of distinct external conditions may be determined, eg, using algorithmic classifiers such as unsupervised learning models.

In the example of the feature source elasticity case, the hue prediction models in the model suite are chosen to complement each other according to the input feature set. For example, the first model in the suite may require a first set of input features (eg, features A, B, and C), and the second model in the suite may require a second set of input features (eg, features A and C) . Depending on the complexity of the input features, additional and/or different models may be provided in the kit. For example, the kit may additionally include a third model requiring input features A, B and D and a fourth model requiring input features C, E and F. For feature elasticity, the number of models in the model suite can be determined by balancing the computational cost with the number of potential failure points. In some embodiments, there are only two models available. In some embodiments, there are two other embodiments. In other embodiments, there are four or more models.

In one example, the real-time model selection framework uses (i) a primary model that performs optimally and uses a first set of input features (eg, IR and light sensor data); and (ii) one or more feedbacks models that perform poorly but use input feature sets that do require the entire first set of input parameters. For example, a backup model may only require readings of a first type (eg, light sensor readings) and readings of a second type (eg, weather feeds) as input features. For example, a backup model may only require a third type of readings (eg, IR sensor readings) and a second type of readings (eg, weather feeds) as input features. If the primary model is executing, when readings of the third type (eg, IR sensors) suddenly become unavailable, the model selection logic may select an appropriate feed-back model to intervene and execute using readings of the first type (eg, IR sensors) , light sensor readings) and models of the second type of readings (eg, weather feeds).

In the example of an external condition change situation, the model suite is selected based, at least in part, on the number of qualitatively distinct weather conditions encountered in a given location where the tone selection logic operates. It should be noted that this architecture can be compared to architectures using a generic model. A generic model can be trained on any available information, such as under all types of external (eg, weather) conditions. In theory, this model can predict all types of future external (eg, weather) conditions, and thus determine the appropriate hue state for all types of external (eg, weather) conditions. However, in some cases, this flexibility may come at the expense of reduced accuracy, increased modeling time, and/or increased computational resources. A trained model that is optimized to predict future conditions under certain specific circumstances is sometimes better than a generic model for those circumstances. An example of a situation where a specialized model may be superior to a general purpose model may be in the case of a fast moving cloud.

As an example of why different models may provide better results, a model optimized for foggy or predominantly cloudy conditions may be saturated when exposed to data from sunny conditions, and therefore may not be suitable for use in sunny conditions Determines the hue state during periods, but will perform better than the generic model during foggy conditions. For example, a fog or cloudy condition-optimized model may provide finer-grained and/or more nuanced images of changing conditions during fog or cloud cover. Training this model uses training data with lower intensity radiation values.

When using a model suite dedicated to changing conditions of external conditions, real-time model framing may involve first identifying groups or types of environmental conditions that can benefit from having their own models, at least one (eg, each) model optimized To predict future external conditions within a range of specific types of external conditions.

In one approach, a setup process identifies a weather condition based at least in part on repeating sets of characteristic values (eg, measured light sensor (eg, visible radiation sensor) and/or IR sensor values) Possible categories, such eigenvalues such as eigenvalue profiles (time series of eigenvalues over eg a part of a day or an entire day). For a given site, characteristic profiles can be collected over a number of days, eg, at least about 100 days, 300 days, or 500 days. Using algorithmic classification tools, products can identify clusters of characteristic profiles. At least one (eg, each) cluster may represent external environmental conditions that require separate models.

In another approach, setting involves identifying the expected need for a different model (eg, optimized for fog, smoke, cloudless sky, cumulus drifting, cirrus, thunderstorms, and/or any other external conditions disclosed herein model) of different types of external (e.g. weather) conditions. For at least one (eg, each) of these different external (eg, weather) conditions, the program may collect characteristic values (which may be provided as profiles over time) and/or algorithmically determine correlation with the different weather conditions Linked pattern.

In some embodiments, there may be four or more models in a model suite, at least one (eg, each) model designed and trained to excel at predicting a particular type (or a particular combination of types) outside ( For example, weather) conditions, eg, as disclosed herein. In some embodiments, there may be at least five, seven, or more than seven such models.

In various embodiments, distinct extrinsic condition types (or clusters) are generated (I) by analyzing historical data (eg, radiation profiles) and (II) by clustering the profiles based at least in part on an appropriate classification algorithm identification, such data can be provided as a time-dependent collection of radiation intensities. A collection of profiles may be acquired over a (eg, long) period, such as one or more months or one or more years. In some embodiments, the profile contains sequential values of a single measured value (eg, raw photosensor measurements of external radiant flux as a function of time).

In some embodiments, the profile clustering is used to generate an average or representative profile, which can then be used for comparison with current radiation data to determine which model to use. Determining which cluster the current condition is closest to can be accomplished using various distance metrics, including, for example, Euclidean distance.

The clustering algorithm can generate clusters of distinct radiation profiles (eg, at least the number of models to choose from). In a properly designed clustering algorithm, the clustering can be based, at least in part, on properties that are meaningful given the tone control logic, such as having different window tone sequences for a given sensor reading. Examples of divergent conditions that cause qualitatively different radiation profiles include weather that produces fast-moving clouds (eg, cumulus clouds), low-hanging clouds or fog, clear and sunny conditions, snow, and/or similar weather conditions.

Suitable clustering algorithms can take different forms. In one approach, radiation profiles can be provided and compared to each other to yield point-by-point distances. In a multi-dimensional section space, sections can naturally be clustered into different groups, which can be associated with different external (eg, weather) conditions. However, this is not necessary, nor is it necessary to explicitly identify different external (eg, weather) conditions associated with different clusters.

In some embodiments, profiles of measured radiation values over time are collected and used to identify clusters. Radiation profiles can span various lengths of time. For example, in some cases it spans at least an hourly or at least an entire day of radiation profiles. Radiation profiles for use in clustering may be collected over a period of at least one (s) hour, one (s) days, one (s) weeks, one (s) months, or one (s) years. Radiation profiles can be collected at least with second or minute resolution. At least one (eg, each) profile can have radiation values collected at least about every second, every minute, every few minutes, every half hour, or every hour. In some embodiments, the values may be acquired at least on the order of minutes (eg, with a resolution of at least one second, seconds, minutes, or minutes). These profiles can be used as at least one basis for clustering. The profiles can be clustered in an unsupervised manner, eg considering which profiles form distinct clusters.

To facilitate the clustering process and/or reduce computational effort (eg, time and/or resources), the size of the data in the radiation profile may be reduced by any of a variety of techniques. A method can map the profile to (eg, still) a dimensionality reduction space that is efficient for clustering. This clustering approach can be implemented by an autoencoder such as the seq2seq framework in Google's Tensorflow. Certain techniques may provide unsupervised pre-training to identify general properties of related profiles that can eventually be clustered together. Computational problems can be reduced by combining data from two or more time periods (eg, days) into a single profile. For example, techniques such as centroid averaging can be used to combine profiles from two or more time periods (eg, days). In some embodiments, k-means clustering techniques are used.

After clusters have been identified, the clusters can be tested. Any of the various clustering test or verification handlers can be used. Examples include: 1. Inertia (sum of the distances of a sample [eg, data instance] to its nearest cluster center) 2. Silhouette score (for each sample the difference between the mean intracluster distance and the mean nearest cluster distance) Difference divided by the maximum of the two) 3. Calinski-Harabaz score (ratio between intracluster and intercluster dispersion) (see Rousseeuw, P. (1986). Silhouettes: Interpretation and Verification of Cluster Analysis Graphical Aid (a Graphical Aid to the Interpretation and Validation of Cluster Analysis. In: Journal of Computational and Applied Mathematics , 20.53-65). (See Caliński T. and Harabasz J. (1974). A Dendrite Method for Cluster Analysis. In: Communications in Statistics , 3:1, 1-27) .

In some cases, the test examines and compares intra-cluster distances and inter-cluster distances.

Clusters of radiation profiles may have identifiable characteristics. Figure 27B depicts examples of characteristic radiation profiles from different clusters. This figure illustrates an example of a characteristic profile of radiation profiles in different clusters. Labeled as follows: (1.) sunny; (2.) cloudy; (3.) partly cloudy; (4.) mixed sunny/partly cloudy; (5.) sunny with occlusion; and (6.) partly occluded partly cloudy. All profiles are day lengths with minute resolution. The Y-axis is the light sensor value scaled from (0 to 779 watts/square meter) to (0 to 1).

In some embodiments, the clustering logic identifies distinctive characteristics of individual clusters of the radiation profile. Various techniques can be used for this purpose. One embodiment uses shapelet analysis. Certain subsets of radiation data points in the profile can serve as characteristic features. Shape sub-feature recognition algorithms may be used. When using real-time model selection, current conditions can be processed, for example, on-the-fly to generate shape sub-features or other features that are compared to corresponding characteristics associated with various clusters of the various available real-time models. A real-time model may be selected based at least in part on which cluster the current conditions are associated with.

In some embodiments, supervised or unsupervised learning is used for clustering. In some cases, clustering is performed using unsupervised learning and, as appropriate, using the information collected and conclusions drawn using the logic in module E discussed in the context of FIG. 25 .

In some embodiments, different types of models should be generated or obtained as they are identified for inclusion in the framework. Accordingly, related workflows generate or select models based at least in part on data from a particular model's profile or other information.

In some embodiments (eg, with input feature elasticity), different models must be trained using one or more different training sets (eg, different combinations of input features may be used). For example, a model can be trained using data with IR sensor readings and corresponding weather feeds, while a model can be trained using data with light sensor readings and corresponding IR sensor readings and weather feeds another model. Yet another model can be trained using light sensor readings and corresponding weather feeds. At least one of these models (eg, each) can have a different architecture.

In the case of a suite of models optimized for different external conditions (eg, different weather types), individual models may (eg, each) be trained on data collected for their own specific types of external conditions. For at least one (eg, each) external condition identified in the setup, the workflow may (eg, only) preserve the model using data obtained when this condition occurs. For example, the workflow may use training data from a first external (eg, weather) condition (eg, foggy morning) to develop and/or test a first model, using training data from a second day's weather condition (eg, cloudy) to develop and test a second model, etc. In some embodiments, at least one (eg, each) performance of the trained model is tested against some benchmarks, such as the performance of a model trained with data from multiple different weather conditions.

The model selection logic may use various factors to select a model for immediate (eg, immediate) or recent hue state determination. The immediate (or near-instant) process of deciding which model to use may depend on immediate or anticipated conditions and/or differences between the available models. For example, in a feature source resiliency condition, the model selection logic can monitor the input parameter source for possible problems. If a failure is observed that has caused or will likely cause an input feature to become unavailable to the currently executing model, the model selection logic may shift (eg, immediately or rapidly) to a different model for which all desired input features are currently available.

In one example, the main model performs optimally and uses the first set of input features (eg, IR sensor and light sensor data), and one or more feedback models perform poorly, but use does require (eg, the entire) set of input features of the first set of input parameters. For example, an alternate model may require (eg, only) light sensor readings and weather feeds as input features. Alternatively, alternate models may require (eg, only) IR sensor readings and weather feeds as input features. Then, if the main model is executing, when the IR sensor or light sensor suddenly becomes unavailable, the model selection logic can select an appropriate feed-back model that does not require IR sensor readings to intervene and execute.

Where the model suite includes models optimized to handle different types of external conditions, the selection logic can monitor the external conditions and periodically determine which model performs best given those conditions.

In some embodiments, this model selection logic uses current data sets (eg, local IR sensor and/or light sensor readings) and/or current information (eg, weather feeds) to evaluate current external conditions (eg, weather feeds). For example, based at least in part on the radiation profile). Model selection logic associates the current external conditions with the most similar clusters or classifications that suggest a particular model. Various techniques can be used to identify clusters or classifications that are most similar to current conditions. For example, if clusters or classifications are represented by regions or points in a multidimensional space, the model selection logic may determine distances (such as Euclidean distances between the current condition and each of the clusters or classifications). Non-Euclidean techniques can be used. In some embodiments, k-means are used to correlate with current conditions. After clustering the current condition, logic selects the model associated with the cluster or classification (associated with the current condition) for execution.

As an example, if the radiation profile changes due to, for example, rising fog or the approach of a storm front, the processed sensor readings may indicate that external conditions have transitioned from one classification of radiation profiles to another, and this transition requires Select a new model optimized for the new radiation profile.

The model selection logic may select models at a particular frequency suitable for real-time control window shading, such as at least one second to several hours. The model selection logic can decide which model to use at a defined frequency, such as every second, every few seconds, every minute, every few minutes, every hour, or every few hours. In certain embodiments, the model selection logic determines which model to use at a frequency of about 5 seconds to about 30 minutes. In certain embodiments, the model selection logic determines which model to use at a frequency of about 30 seconds to about 15 minutes. In some embodiments, the model selection logic selects a model when triggered by a detected event, such as a detected change in the radiation profile greater than a defined threshold.

Within a model suite, those models that are not currently used to determine hue state may need to remain ready for execution. All models in the suite may be retrained in time (eg, daily or on some other periodic basis (eg, between every 1 and every 10 days)). In certain embodiments, at some time when the real-time model is not executing, such as during a low occupancy time in the facility (eg, at some time during the night, such as at midnight or at any other low occupancy time, eg, as described herein ), retrain the models.

In some embodiments, all models must be ready for deployment when hue decisions are being made (eg, during daylight hours). Data required for all models, in particular, data including historical components (such as rolling average sensor data) should be kept up to date and ready to serve as feature input for newly selected models, eg even if they are not used for the current implementation The same is true in the model. In various embodiments, all input features of all models are constantly generated or otherwise kept up-to-date and ready to be fed into the models.

When the model that is not currently used to determine the hue state is a recurrent neural network, it may be necessary to feed it input features and have it execute (eg, even if its output is not currently used) so that if the model is selected, its Provides useful output when ready. If the model is not time-dependent (eg, it does not include memory and/or does not have a feedback loop as in the case of a feedforward neural network), then the model need not be executed until it is needed to determine the hue state.

28 presents a block diagram of an example architecture 3001 for a real-time model selection framework. The framework relies on real-time model selection logic 3003 , which may be implemented as program instructions and associated processing hardware. Logic 3003 receives various inputs related to current external conditions. In the depicted embodiment, these inputs include local sensor data 3007 and remote data 3009 , such as weather feeds provided via the Internet. The real-time model selection logic 3003 can access the signature 3011 or other stored information that allows the logic to compare the current condition with previously classified condition types. In some embodiments, the classification signature is a shape sub-feature. By applying classification logic to current conditions, real-time model selection logic 3003 determines from among a plurality of condition-specific models which type of model it should select to predict future conditions. When making this decision, logic 3003 selects a model from among those in the suite 3005 of available condition-specific models. In the depicted embodiment, there are six models available.

In some embodiments, the real-time model selection framework uses sensor data and/or current condition information. Examples of sensor data include photodetector and/or IR sensor inputs. Current condition information may be provided, for example, via real-time weather feeds from, for example, selected third-party application programming interfaces (APIs).

In some embodiments, input elasticity is one application of this framework. In addition to those from hardware units (eg, rooftop sensor units, such as those described in US Patent Publication No. 2017/0122802, published May 4, 2017, which is incorporated by reference in its entirety) In a prediction model that utilizes real-time weather data from third-party APIs in addition to light and/or IR sensor inputs (incorporated herein), there are three possible points of failure. Because any of the three inputs may or may not be present during a connection failure event, there are (eg, only) frameworks that support real-time model selection that can be handled seamlessly without downtime (eg, at least about 8 (or 23)) possible input combinations.

Unlike sensor data, third party weather data cannot be reliably synthesized from historical values using techniques such as weighted centroid averaging. However, experimental results have shown that it is helpful to supplement the model with real weather data, for example when connections to one or both of the sensor inputs are missing and/or must be synthesized. Because a given model can only execute when all expected inputs are provided, both models should be ready for deployment in the event of a connection failure (e.g. one model includes a network footprint ready to receive input from a real-time weather feed , while the other model does not).

With this architecture, the real-time model selection framework (eg, only) utilizes real weather data when it is available, and the framework (eg, only) synthesizes sensor values for any inputs that are missing, preserving what is received (eg, only). each) actual data points. In this way, the presence or absence of every minute input drives model selection in real time, ensuring that the currently deployed model supports the combination of currently received inputs.

In some embodiments, this method (and associated architecture) enables deployment of a single architecture with specialized models to locations currently equipped with (eg, only) light sensor hardware units. If the location prefers to maintain two versions of the hardware when it receives the upgrade (for example, one type of sensor on one building, and an upgraded version of the sensor on another building), the real-time model The architecture of choice may support the simultaneous deployment of two predictive models that are (eg, each) optimized for the input it receives from its corresponding hardware unit. In this way, the framework can provide the versatility of sensor prediction software.

To verify the resiliency of the real-time model selection framework, extreme variation stress tests can be designed that randomize the inputs to the prediction module within each time period depending on the resolution (eg, every minute). This test can simulate a situation where the presence or absence of (eg, any) of the three inputs is randomly determined. From one minute to the next, all, none, only one, or any combination of the two inputs can be made available to a prediction module that instantly selects which of the two models designed for those inputs one of. For the duration (duration of each of the seven days) the period forecasting module was stress tested, deploying the real-time model selection framework resulted in zero downtime, successfully producing minute-level forecasts for a full day. Figure 29 presents the results of a stress test run from noon to sunset. Line 3103 (designated "All Input Forecast") represents the forecast produced using all inputs (light sensors, IR, forecast IO data from weather feeds). Line 3111 (designated "Actual 10 Minute Max") represents the predicted actual value; eg, the radiation intensity actually measured from the outside. Line 3119 (designated "Weather Forecast Only") represents the forecast generated using forecast IO data and synthesized light sensor and IR data. Composite data is generated by averaging the centroids of data from the last few days. Line 3105 (designated "Sensor-Only Prediction") represents a prediction generated using only real light sensors and IR data. Line 3107 (designated "No Input Prediction") represents the prediction produced using only the synthesized photosensor and IR data. Line 3117 (designated "IR Prediction Only") represents the prediction generated using synthesized photosensor data and real IR data. Line 3102 (designated "Light Sensor Prediction Only") represents the prediction generated using real light sensor data and synthetic IR data. And line 3131 (designated "Debug Forecast") represents the forecast produced by the model subjected to the stress test, where the presence or absence of any of the three inputs to the model is randomized minute by minute. The prediction shown as line 3131 is generated using real-time model selection of two models, one model is designed to accept light sensor data, IR sensor data and forecast IO data, and the other model is designed for Only light sensor and IR sensor data are received. All other curves were generated using a model that received data from all three sources: light sensor data, IR data, and predicted IO data. Because the real-time model selection run (line) transitions back and forth between the two models, the forecasts produced fluctuate across the range of forecast values output by all previously described models. However, although line 3131 fluctuates, it remains reasonably close to the actual measured value of radiant flux (line 3111 ), thus indicating that it provides a reasonable prediction under challenging conditions.

In some embodiments, deep learning capabilities rely on informative signal strengths of input features whose relationships are represented by network architecture layers. It may not be possible to predetermine which set of baseline input features results in the best predictive performance in (eg, all) geographic locations and at (eg, all) times of the year. There may be a variety of possible input features for a neural network, sometimes hundreds or more. As mentioned herein, some instances have about 200 input features available. However, using (eg, all) of these features can lead to certain problems, such as overfitting and/or requiring additional computing resources, which increases cost and/or slows down the program.

In some embodiments, the neural network is a "black box" algorithm in some aspects. It may not be possible to directly quantify the relative importance of input features. For such networks, no matter how many representation layers are constructed, (i) model relationships between inputs and/or (ii) relationships (other relationships...) effectively mask the relative importance of input features. This property of deep learning models can make it difficult to determine whether the set of input features currently being used is optimal. Different sets of input features can train different sets of relationships (other relationships...), and neural representations that replace the baseline feature set can more successfully minimize overall prediction error. The variety of site-specific external conditions and their varying and/or irregular rates of change can make manual tuning of model input features impractical.

In some embodiments, machine learning is used to automate feature selection procedures that might otherwise require monitoring by a panel of experts tasked with regularly updating model parameters. In some embodiments, automated feature selection is implemented by integrating a machine learning module into the initialization framework of a model for predicting future values of window shading and/or local weather conditions. This feature selection module can be configured to quantify and/or (eg, empirically) verify relative feature importance. In some embodiments, this information allows the predictive model to be automatically re-initialized with new inputs and/or feature sets updated for changes such as different locations and/or different times of the year.

In some embodiments, conditions prevailing at a particular time and/or location may determine which set of input features is best for minimizing prediction error. Changes in site-specific conditions over time can drive reinitialization of the model with an improved set of inputs, enabling it to automatically self-correct and/or update its existing parameterizations.

In some embodiments, the program effectively filters one or more of the various available input features. Although various filtering procedures can be used, the following discussion focuses on a recursive feature elimination procedure (RFE), which can be implemented by regression and/or classification methods such as support vector machines or random forest techniques.

The disclosed techniques may allow a recursive feature elimination system to identify, from among all possible feature inputs, the specific feature input that is likely to be most valuable on any given day. Therefore, a relatively small set of input features can be used to initialize and/or run the model. Therefore, execution of the prediction routine may require only reduced computing resources and/or time. Execution of prediction routines can reduce model errors, such as inaccurate predictions of future external conditions associated with selecting hue-appropriate window hue states.

As suggested herein, a recursive feature elimination procedure (RFE) can be used to capture (i) weather data at different locations (eg, even within the same city or block) and/or (ii) at different times of the year and and/or behavioral differences in weather characteristics. An input feature set that works well at one location may not work well at a different location. A feature set that worked well in early February may not work well in mid-March. Whenever a new set of input features is selected, it can be used to re-initialize a neural network (such as a dense neural network and/or a recurrent neural network) used to predict future hue states and/or weather conditions .

In some embodiments, the feature elimination system identifies the relative importance of feature inputs. The program may use various features derived from light sensor and/or IR sensor input as described herein.

In certain embodiments, the model that is periodically reinitialized (eg, as described herein) is a neural network (eg, as described herein), such as a dense neural network and/or a recurrent neural network ( For example, LSTM). In certain embodiments, the model is configured to predict external conditions at least about five minutes into the future. In certain embodiments, the prediction is further extended into the future, such as at least about 15 minutes or at least about 30 minutes into the future. In some embodiments, the extended period is no longer the maximum time period required to transition from any one hue state to a different hue state.

In some embodiments, the submodule for filtering input features is configured to perform support vector regression, or more specifically, a linear kernel support vector machine. Algorithmic tools of this type can generate coefficients for all available input parameters. The relative magnitudes of the coefficients can serve as quantitative indicators of the relative importance of the associated input parameters. The feature filtering submodule can be embedded in the feature engineering pipeline used to preprocess the input of the neural network during model training. As an example, see Figure 30 described below.

In some embodiments, SVMs are used for regression contexts rather than classification contexts (eg, for SVMs). Mathematically, two procedures can generate the hyperplane and identify the data points closest to the hyperplane. Through this procedure, the support vector machine can identify coefficients for the feature input, which can be used to specify the importance of the feature input. In some embodiments, the generation of coefficients for different feature types is common to partial least squares and principal component analysis. In some embodiments, unlike principal component analysis, support vector machines do not combine feature types into components and/or present independent feature inputs separately.

In some embodiments, the "support vector" of a SVM is a data point that is outside the error threshold, and the SVM is working on a predicted target variable (eg, watts/square meter for a light sensor, Fahrenheit or Celsius for IR sensors, etc.) to tolerate this error threshold when regressing the underlying model input. When training a support vector machine, (eg, only) these data points can be used to minimize prediction error, such as ensuring relative feature importance is quantified with respect to those conditions that cause the most difficulty for the model.

In some embodiments, the regression analysis uses historical data points acquired at a given time (eg, noon on a particular winter day), and each data point includes (i) the value of a single putative input feature (eg, within the last 10 minutes) the rolling mean of the IR sensor readings within the eigenvalues of the same light sensor). The raw measured external radiation values can serve as markers and/or as independent variables for regression analysis.

In some embodiments, the input to the regression analysis is a single data point for each putative input feature. Some input data points (putative input features) may have associated time values. Except for that time value, the data points may represent the same feature type as one or more other input points. Some or all of the input features may have time lags, such as four or more time steps. For example, the five-minute rolling median of the smallest measured IR value can be determined by four model parameters (eg, which are at time indices "t", "t-1", "t-2", and "t-3" value) means that some of these model parameters can be selected by RFE. Thus, at each time interval, such as every minute (eg, in each column of the input data structure), the model may contain some information about how that characteristic changed during the previous four minutes.

Support vector regression (or another regression technique) may be used to develop an expression (or relationship) between coefficients (eg, with their putative input characteristics) and external radiation values. An expression can be a function of the input eigenvalues and their associated correlations. For example, the expression may be the sum of the products of the coefficients and the values of their associated inferred input features.

In some embodiments, an error minimization routine is used to adjust the coefficients, eg, so that the calculated radiation values generated by the function match the measured actual radiation values (eg, the light sensor values acquired to generate the eigenvalues) . Regression techniques may use calculations used by support vector machines to classify the marked points. The program can eliminate those features that contribute the least to minimizing prediction error. Regardless of the particular technique used, the program can generate a regression expression with coefficients for at least one (eg, each) eigenvalue.

In some embodiments, a feature elimination procedure initially applies regression to all potential input features, and through this procedure, features are ranked based at least in part on coefficient values. One or more putative input features with low magnitude coefficients may be filtered out. Then, the program can apply regression again, but this time with a reduced set of putative input features that have been reduced by eliminating some of the low-ranked input features from the previous regression. The program may continue recursively as many loops as is appropriate to reach the desired number of input features. For example, the process may continue until a user-defined stopping criterion or a requested number of remaining predictors (eg, a threshold value) is reached.

The resulting set of features can then be used to initialize the neural network (eg, with the most efficient input configuration). A decision can be made to re-initialize the model with the new configuration of the input features as to how well the existing input features perform against the same validation set of recent historical data.

While support vector regression may be a suitable technique for filtering and/or eliminating putative input features, it may not be the only suitable technique. Other examples may include random forest regression, partial least squares, and/or principal component analysis.

In some embodiments, the "recursive" elimination procedure runs the filtering algorithm (eg, linear kernel support vector regression) multiple times, each time obtaining a greater degree of filtering. Through this method, a step-by-step procedure can eliminate the least significant feature inputs, eg, by running the filtering algorithm multiple times. Parameters, which can be user definable parameters, can specify how many features to select at the end of the recursive filtering procedure.

In some embodiments, a fixed number of features are eliminated each time a support vector machine is run with a set of potential input features. For example, in each iteration, a single feature can be eliminated and then the support vector machine can be re-run with one less data point. As an example, if initially there were 200 input features available and each time the SVM was run, another input feature was eliminated, the SVM would have to be run 100 times to reduce the number of input features from 200 to 100.

In certain embodiments, the RFE process removes about 20% to about 70% of the initial number of available features. In certain embodiments, the RFE process removes at least about 10%, 25%, 50%, or 75% of the features. In certain embodiments, the RFE process removes about 50 to about 200 features. As an example, there are initially 200 distinct input features and in the RFE procedure, 100 of these (50%) are filtered out to reduce the number of input features to 100 features at the end of the procedure.

In some embodiments, input feature cancellation is flexible in identifying features to filter. For example, in a given iteration, any type of feature can be filtered. Consider, for example, a situation where there are 50 input features based only on static sensor readings, and those 50 input features are in each of four different time intervals (eg, each of the four consecutive minutes preceding the current time within one minute). Therefore, in this example, there are 200 input features available. The elimination handler may consider eliminating some features at one time interval, eliminating other features at a different time interval (eg, time interval or time step), eliminating still other features at a third time interval, and so on. Some feature types may be retained for more than one time interval. Accordingly, the elimination process may eliminate features based at least in part on feature type (eg, rolling light sensor mean vs rolling IR sensor median) and/or at least in part based on time delta (compared to current time) .

In computational model design, there may be various stages of model definition and development. One of these phases can be initialized. In some embodiments, the program initializes or reinitializes the model at least once (eg, each time) a new set of input feature types is defined.

(1) Model Architecture - In the case of a neural network, this may represent the overall structure of the network including several layers, at least one (eg, each) node in a layer, and connections between nodes in adjacent layers . (2) Model hyperparameter optimization - setting hyperparameters before training. As an example, a hyperparameter may be an initial (before training) set of parameter values for one or more parameters in the startup function of an individual node in the network. In another example, the hyperparameters to be optimized include initial (eg, prior to training) weights for individual nodes. Hyperparameters can be used to define how the model learns. For example, it can set the rate at which the model learns with techniques such as gradient descent. (3) Initialization - Once the hyperparameters are set, the model is initialized by defining the set of input feature types that will be used. The initial training of the neural network model using the input feature set is initialization. The model may be trained with the new set of input feature types when the model is reinitialized at least once (eg, each time). (4) Learning - By initializing the model, the training algorithm uses the training data set with input feature values and associated labels to train the model.

Figure 30 presents a flowchart 3201 showing one implementation of a procedure for model update using periodic input feature filtering. The following may be performed: (a) Receive a large set of potential input features (eg, more than about 100 features derived from historical values of frequency-specific sensor readings). See operation 3203 . (b) Perform initial feature filtering (eg, using SVM RFE) on the entire set to identify the first subset of input features. See operation 3205 . (c) Initialize and train the model with the current subset of input features. See operation 3207 . (d) Use the current trained model to predict window tone conditions and perform transfer learning periodically (eg, daily). See operation 3209 . (e) Check if the input feature set is revised (eg, wait a threshold number of days, such as about three to ten days, since the model was last re-initialized). See operation 3211 . (f) When needed, re-run input feature filtering with a large set of latent input features, but update it with data obtained since the last time the model was initialized. An updated subset of input features is identified and the model is reinitialized and trained. See operation 3213 . (g) Compare the performance of the updated model with the new feature set to the performance of the previous model (which may be the current model). See operation 3215 . (h) If the new model performs better, set it as the "current" model (see operation 3217 ) and loop back to operation 3209 ( d ) with the new model and the updated feature subset; if not, continue The previous model as indicated at operation 3217 is used.

In some embodiments, to ensure that premature model reinitialization does not gradually compromise the results obtained by other periodic optimization routines such as transfer learning procedures (which may be performed periodically (such as nightly) using the retraining module) The performance gain can be compared to the predictive ability of the model generated by RFE and reinitialization with the predictive ability of the model optimized by transfer learning or other routine retraining techniques. This can be illustrated by operations 3215 and 3217 in FIG. 30 . If the regular model outperforms the model with RFE reinitialization, the previous set of input features can be preserved. Optionally, the coefficient weights of the existing predictors are updated so they can be reused to initialize the next regression analysis. If the RFE reinitialized model outperforms the normal retrained model, the input feature set is self-correcting without user intervention.

In some embodiments, embedding SVM-based recursive feature elimination into a (re)training module allows for condition-driven model parameterization and reinitialization that prevail at a given location and at a given time of year. In this way, the neural representation of the model input can be prompted to continuously compete with itself. The results could be applications of artificial intelligence that learn from the most difficult situations, remember what is still useful, forget what is not, and self-correct when finding better solutions to the problems at hand.

Figure 31 shows an example of a retraining architecture.

Recursive Feature Elimination - Summary Points: u Improve the input feature set over time and by location to filter out additional inputs u Spreading meaningful signals within less useful features can hinder model convergence u Embed machine learning submodules into deep learning pipelines u Can use linear kernel support vector regression (SVR) to quantify feature importance u SVR model fitting focuses on the most difficult data points, known as "support vectors" u recursively eliminate features that contribute less to minimizing the loss function u User input defines the number of original features to keep (eg, 200+ features) u Model initialization can apply RFE to identify the best baseline feature set u The optimal feature set is not static, varies by location, and changes throughout the year u The most efficient model parameterization is unknown and hand tuning is impractical u RFE can be used to automate self-correcting feature selection u Transfer learning and RFE model reinitialization may periodically conflict with each other u Validate model performance on recent historical data u If transfer learning outperforms RFE reinitialization, keep features and update weights u If RFE reinitialization outperforms transfer learning, the feature set is self-correcting u prevailing conditions thus drive parameterization and model reinitialization

Certain implementations use a virtual sky sensor application (sometimes referred to herein as a "virtual sky sensor" or "VSS") that can host forecast data or test data for control logic Consumption, the control logic makes decisions based at least in part on the data to control one or more systems (eg, window control systems) at the site. Statistical post-processing can be applied via the VSS module. Virtual sky sensors may be used, for example, in forecasting, A-B testing and/or quality assurance (QA) data simulation. In a prediction use case, a virtual sky sensor application may host prediction model output (prediction), such as predicted sensor data from a deep learning application (eg, a deep neural network (DNN)), and the The forecast sensor data is passed to the control logic. In another example, the virtual sky sensor application may host test cases for various conditions (eg, test data suites for quality assurance purposes. The test cases may be passed to the control logic to determine the control logic Behavior under various conditions. In another example, a predicted data set is delivered by the VSS, and an actual (eg, measured by a real physical sensor) data set is delivered from the physical sensor to the control system , eg, using a replicated site configuration. A control system (eg, a master controller) may, for example, use the replicated site configuration to run a side-by-side comparison of performance.

The testbed enabled by the virtual sky sensor can track and evaluate the performance and performance of different prediction models (e.g., tonal acceleration, error metrics, on-platform CPU and memory usage) on various location configurations, such as In a controlled experiment on a (eg, a single) control system. The same virtual sky sensor interface may provide a data simulation framework for, for example, quality assurance and other testing of predictive models under conditions that may be infrequent or difficult to replicate. Hosting the prediction model output via a virtual sky sensor may allow for accelerated tone commands, eg, without having to change existing code and/or data infrastructure. Different combinations of data from instances of VSS implementations can be hosted by VSS in parallel. One or more virtual sky sensors may be used.

In some cases, VSS hosting may pass data to control logic such as window control logic. For example, a virtual sky sensor may host sensor data and/or weather condition predictions to pass to Module C and/or Module D of the window control logic described herein. In instances where the VSS hosts predicted sensor data from a deep learning application (eg, a deep neural network (DNN)), the deep learning application may reside on the control system. In some aspects, the control system may not include deep learning applications. For example, the VSS may host test data for Module C and/or Module D for testing the window control logic.

In some embodiments, a virtual sky sensor application is configured to interface and interact with control logic, such as a physical sky sensor, such as having a plurality of sensors (eg, infrared sensors and/or light sensor) of a sensor set (eg, a ring sensor). The virtual sky sensor application can run on the local host IP address. In some cases, a data fetcher application (eg, Viewfetcher) inserts forecasts (eg, weather conditions and/or sensor data) hosted by the virtual sky sensor application into a database, such as residing in Field database on the control system. In one aspect, the virtual sky sensor is a third-party API.

In some embodiments, the VSS is a web application/server. In some embodiments, when VSS receives a request for data from a data fetcher application (eg, Viewfetcher), fetches predictions from a live database, VSS performs calculations on the data, and transmits the data through the data fetcher application Go back to the field database on the control system (eg, the main controller). A data fetcher application (eg, Viewfetcher) can reside on the control system and/or in the cloud. In some cases, the virtual sky sensor application and/or location monitoring system resides on a computing device at the location.

The Flask Python library (or similar application library) can be used to individualize the virtual sky sensor implementation into an (eg, web) application running on the local host at a user-specified port. In this case, the data extractor platform can point to a user-specified port number, eg, using a user interface such as a location management console. After execution, the Flask application responds to requests for XML-formatted sensor data from the data extractor, which the application processes by querying the data source. In one example, the data source is a table of recent forecast values stored in the database. In another example, the data source is a repository of data frames containing simulated values corresponding to the test cases being executed. Existing prediction modules (eg, module C and/or module D) may consume sensor values inserted in the field database, just as they would consume actual sky sensors generated by physical sky sensors such as ring sensors. The sensor data is the same.

In some implementations, multiple virtual sky sensors may be used to host sensor values, but in performance comparisons for A/B testing, in test cases completed by a quality assurance (QA) test suite, and/or in There are many predictive models and/or test conditions used in forecasting use cases. Under this multi-VSS architecture, network controllers and window partitions can be assigned to receive control commands driven by sensor values passed by the VSSs assigned to them. A benefit of the multi-VSS architecture for the predictive usage implementation may be that it can support directional sensor radiation modeling. In this case, a single master controller can execute multiple prediction models whose sensor values are hosted using distinct virtual sky sensors.

Certain aspects relate to prediction use cases using virtual sky sensors (eg, virtual sky sensors that host predictions determined by a deep learning application). In some embodiments, a deep learning application (eg, DNN) obtains real-time (eg, real-time) sensor data detected by physical sky sensors (eg, ring sensors), performs calculations to determine predictions, And the prediction is passed to the virtual sky sensor. The virtual sky sensor application can host predictions from deep learning applications, for example, to pass the predictions to a database. Control logic may then retrieve predictions from the database for consumption. For example, predictions from a DNN on a (eg, a master) controller can be saved to a database (eg, on a controller or elsewhere coupled to a network), and the controller's control logic can be based at least in part on Hue decisions are made based on predictions retrieved from the database. Data from the VSS can be communicated (eg, passed) to the database, as data detected by physical sky sensors.

In some implementations, the virtual sky sensor communicates (eg, passes) the forecasted or predicted data (forecast or forecast) computed by a deep learning application (eg, DNN) to the control logic for consumption. For example, a DNN may be used to output one or more predicted sensor values (eg, IR sensor values and/or light sensor values) and/or one or more conditions (eg, weather conditions). The virtual sky sensor can instruct the data extractor application (in response to a request from the data extractor) to save the forecast data from the DNN to or be accessed by the control system (eg, as disclosed herein) database. Control logic may retrieve the values saved to the database to make tint decisions and/or control tint states in one or more partitions of the optically switchable windows at the location. In some cases, the DNN used is a sparse DNN with a reduced number of model parameters from the total number of model parameters in the DNN that would be used to implement the full set of models and modules. Example techniques that can be performed to eliminate model features to a subset of the total number of potential features include linear kernel support vector machines (SVMs), stochastic maximum using information-theoretic metrics (eg, Fisher information metrics or other similar metrics). Optimization, Principal Component Analysis (PCA), or any combination thereof. In one example, a linear kernel support vector machine (SVM) (or other similar technique) is implemented to eliminate model features to a subset of the total number of potential features to be used. In another example, a stochastic optimization using an information-theoretic metric (eg, Fisher information metric) is performed to eliminate model features to a subset of the total number of potential features to be used. In yet another example, PCA is performed to eliminate model features to a subset of the total number of potential features to be used. In certain implementations, two or more techniques may be used in combination, eg, to eliminate model features to a subset of the total number of potential features to be used. In some cases, centroid averaging may be used to determine a composite real-time sensor value based at least in part on historical sensor data, and to determine a one-day mean sensor based at least in part on the composite real-time sensor value profile. The DNN may output predicted sensor values using input features based at least in part on synthesized values from centroid averaging. For example, the DNN may output predicted infrared sensor (IR) values and predicted photo sensor (PS) values about 7 minutes in the future, 10 minutes in the future, 15 minutes in the future, etc.

Certain aspects relate to quality assurance (QA) or other types of testing using one or more virtual sky sensors to host simulated data for testing the behavior of control logic under various conditions. For example, VSS can host simulation data used to test the behavior of intelligent control logic under various weather conditions. Test data can be provided by the user interface of the site monitoring console. The virtual sky sensor application can host the simulation data and pass this test data to the control system or a database accessible by the control system, eg for use by the control logic. In these test implementations, a virtual sky sensor can be used to provide a framework by which to execute a test suite of test cases on predictive models that require a certain percentage of sensor values over a specified time range. These changes can facilitate simulation of conditions that might otherwise require several days of waiting time to arise. For example, instead of having to wait until various weather conditions naturally arise, simulated data can be fed into a virtual sky sensor to generate test data for the various weather conditions of the test suite.

In certain implementations, a test kit may include simulated test data for correlating varying types of conditions and other types of events associated with different levels of sensor readings, such as light sensors and/or IR sensing device level. For these different levels of sensor readings in the test data, eg depending on the time and date of the day, different structures of the control logic may behave differently. For testing purposes, a test data suite can be developed with different sensor levels that produce reproducible control situations. In one implementation, the test data hosted by the VSS and passed to the database may include: time and date stamps, sensor values (eg, light sensor and/or IR sensor levels) and/or Other relevant information for the test case. Example test cases will verify proper hue locking behavior during changes in weather conditions (and sensor values) that occur within the time frame of the defined control logic change used to issue the hue command (eg, >200 watts during the day) /m² = T3, but T4 in the morning/evening when the sun angle is low and the risk of glare is high). Test conditions can be pre-replicated using user-supplied sensor values, eg hosted by the VSS.

A/B testing refers to a randomized experiment with at least two variants A and B. In this test, the site configuration (eg, network controller (NC) and partition configuration) can be replicated on a single master controller where the control logic receives both real and virtual sky sensor values to evaluate and/or compare the performance of predictive models in an experimental setting controlled by the system.

In some embodiments, A/B testing is performed by using one or more virtual sky sensors to host data sets based at least in part on predicted and/or calculated sensor values from a predictive model and Conducted on a data set from actual (eg, real) physical sensor readings acquired by physical sensors, eg, to evaluate the performance of predictive models. In an A/B testing implementation, the site configuration can be replicated on the primary controller. For example, replication mappings of network controller identifiers (IDs) to partition IDs, partition IDs to terminal/leaf controller IDs, and terminal/leaf controller IDs to window IDs.

In some embodiments, A/B test evaluation is performed by using a virtual sky sensor to pass predicted and/or calculated sensor values (virtual sky sensor values) from a prediction model to Control logic, and may pass actual sensor values from physical sensors (eg, sensor sets such as ring sensors and/or sky sensors) associated with another replication site configuration to control logic. Control logic can calculate control levels, such as hue states, for the configuration of the two locations, and can track the performance of these control levels. This may allow a side-by-side comparison of (a) control levels calculated using predicted and/or calculated sensor values from a predictive model and (b) control levels calculated using actual sensor values. In some implementations, instead of duplicating the entire site configuration, one or more partition configurations are duplicated on the primary controller and a similar A/B test evaluation is performed. In some implementations, the A/B test evaluation is performed by using a virtual sky sensor to communicate predicted and/or calculated sensor values from a first set of one or more prediction models to control logic; and using virtual sky sensors to communicate predicted and/or calculated sensor values from a second set of one or more different prediction models to control logic to evaluate and compare the first set of prediction models performance with the second set.

In some A/B testing implementations, performance metrics are used to compare the performance of control levels determined using predicted sensor values from a predictive model to those detected using physical sensors such as ring sensors The performance of the control level determined by the actual sensor value. Some examples of efficacy measures include: difference in glare protection amount, difference in sunlight amount, difference in average acceleration amount of hue transition, and/or any similar efficacy measure. Efficiency metrics may be further subdivided into categories such as with respect to: average weekday (eg, 8:00 am to 6:00 pm), average transition time of a slice based at least in part on a particular busbar configuration, and/or its similar.

In one embodiment, the site configuration (eg, the first site configuration and the second site configuration) is replicated on the (eg, primary) controller. The controller may be any controller of a control system, eg, as disclosed herein. Test data for A/B testing can be sent back to the database. Calculated sensor values (eg, predictions from the DNN) can be passed from the VSS and passed back to the database for the first location configuration. Real physical sensor values from local and/or remote sources can be passed back to the database for configuration at the second location.

In some embodiments, the virtual sky sensor application interfaces with a location monitoring console or other user interface to receive input. "Location Monitoring Console" may refer to a user interface (UI) that may be used by an operator as a means of setting parameters for location-level customization of one or more applications, the one or more applications Control (eg, monitor) the function of the system at one or more locations (eg, control the IGU). In some implementations, a site monitoring console or other user interface can interface with one or more VSSs. For example, a site monitoring console (or other UI) can be used to set parameters that are used by the VSS to determine which sensor values (or other data) have been communicated back to (eg, the master) controller ( For example, on-site) database. For example, if a change in parameters is requested at a certain location to determine and/or implement a tint state for an optically switchable window that will more conservatively prevent glare, the parameters can be set and used by VSS to calculate sensor values, And the calculated sensor values are passed back to the field database, which will be captured and used by the prediction model to determine more glare conservative hue states. As another example, if at a certain location more sunlight is requested to enter a partition of the optically switchable window such that the darkest tone state (eg, tone level 4) is not used, then parameters can be set for that partition and used by VSS To calculate a sensor value below an upper threshold value associated with the darkest tone state, for example, such that the prediction model will determine that there will be less than the darkest tone state.

The user interface of the site monitoring console (or other component) may support a user (eg, an operator) to enter fields for QA testing and/or A/B testing. For example, a site monitoring console may include a user interface that supports the user to enter fields (eg, timestamps, sensor values) for test cases related to QA testing. The simulated data retrieved by the virtual sky sensor from the QA database can be generated (eg, automatically).

A site monitoring console may interface with systems at one or more sites to monitor the function and/or output of components such as sensors, controllers, or other devices. A site monitoring console may allow a user (eg, an operator) to (i) enter information and/or (ii) view details of the status of one or more components at the site. The user interface can display logs and/or performance reports (sometimes referred to as "dashboards") on various components.

In certain embodiments, a site monitoring console interfaces with a site window control system. The control system can retrieve data from a database, which can be used to analyze information from the location to determine when to adjust the controls of the device. In some implementations, the control system includes control logic (eg, with a deep learning application (eg, DNN)) that can (I) learn from data such as local and/or remote sensor data and /or (II) adapt its logic to meet user and/or client goals. In some embodiments, the control logic can learn how to best conserve energy, sometimes by interacting with the lighting system, HVAC system, and/or window system of the location, and modify controller settings accordingly, as appropriate. By doing so (eg, at multiple locations and/or multiple times at a location), new energy control and/or conservation methods can be learned at one location and deployed at other locations. In some implementations, learned weights and/or values associated with one or more layers (eg, hidden layers) of the DNN may be extracted. Such weights and/or values may correspond to parameters of interest. Parameters of interest may include: user goals, customer goals, parameters related to energy conservation (eg, parameters related to energy conservation with respect to location lighting systems, HVAC systems, and/or window systems), or any combination thereof. In some implementations, the control system may extract learned weights and/or values associated with one or more layers (eg, hidden layers) of the DNN, eg, to implement correlating one or more controller settings with one or more One or more learning rules associated with individual user and/or client goals.

"Location" means a site that includes a facility, which facility includes a building and/or at least one structure. A location may include interactive systems including one or more controllers that control devices at the location. The location may have a local sensor that provides local sensor data. For example, a building may have a ring sensor located at or near the building with a light sensor and/or an IR sensor that provides local sensor data. Remote sensor data may be provided from other sources such as weather feed data. Local and/or remote sensor data can be used to make decisions to control devices (switchable optical devices, such as electrochromic devices) at the site. At times, virtual composites can be used, at least in part, to make this decision. In some cases, one system may control the function of elements of different systems. For example, the window control system may send commands to the lighting system and/or the HVAC system, such as to adjust the level of illumination in a location (eg, a room) or enclosure of a partition where the control system controls the tint level of a window and/or Air conditioning level.

Systems at that location may use APIs to allow external systems to access data and/or functionality that is otherwise opaque to external systems. The API may provide syntax and/or entry to allow access. For example, an API for controlling the system may allow for handshaking of access window sensor data (eg, temperature) via URL, username, and/or. HomeKit-compliant and Thread-compliant are commercially available examples that provide third-party APIs for controlling devices from other technology companies including NEST and Samsung (Samsung Group of Seoul, Korea). Thread and HomeKit define standard connection protocols for message passing.

32 is a schematic diagram of a system 3200 including one or more interactive systems interfaced with each other at a location, according to an aspect. The system 3200 includes a location management console 3210 configured to monitor one or more locations and a virtual sky sensor application 3211 in communication with the location management console 3210 . The location management console 3210 is configured to receive user input and interpret the information. In this example, the location management console 3210 is configured to receive user input including the ID of the partition and/or the ID of the device to the virtual sky sensor application 3214 or to devices such as ring sensors and /or a mapping of the physical sensors of the sky sensor set. In some cases, the site management console 3210 is an API that can interface with systems external to the site.

The system 3200 includes a master controller 3250 having: a data extractor application 3252 ; a field database 3254 that communicates with the data extractor application 3252 to insert data into the field database 3254 ; control logic 3256 , It has a prediction model in communication with field database 3254 to receive sensor data and send predictions saved to field database 3254 . The field database 3254 may include one or more of a local sensor database, a weather feed database, a forecast database, and a QA test case database. The data extractor application 3252 communicates with the virtual sky sensor 3212 to send requests for data to the virtual sky sensor 3212 and to receive the data. Data extractor application 3252 communicates with data source 3220 to receive local sensor data from local sensors, such as ring sensors, or remote data sources, such as weather feed data, via third-party APIs. end sensor data. Control logic 3256 includes a deep neural network (DNN) 3258 that generates predictions such as forecasted sensor data and/or forecasted weather conditions. Control logic 3256 communicates with field database 3254 to receive sensor data and insert predictions determined by DNN 3258 into field database 3254 .

The system 3200 includes: a first network controller 3262 in communication with a plurality (three) of leaf/terminal controllers of a first partition ("Partition 1") of a control device (eg, a tintable window); and a second A network controller 3264 in communication with a plurality (five) of leaf/terminal controllers of a second partition ("Partition 2") of the control device. In other implementations, fewer or more network controllers, partitions, and leaf/terminal controllers may be used.

32 is an illustrative example of a predicted usage context according to an aspect. In this implementation, DNN 3258 obtains real-time sensor data communicated from physical sky sensors of data source 3220 , performs predictions, and passes predictions to VSS 3212 . Data extractor 3252 requests data from virtual sky sensor and VSS 3212 , and data extractor 3252 inserts predictions from DNN 3258 into field database 3254 for consumption by control logic to determine control commands. The control commands are communicated to the first network controller 3262 to control partition 1 of the device, and to the second network controller 3264 to control partition 2 of the device.

In some implementations, data entered by an operator at a user interface (eg, a site management console) is used to assign a partition ID or device ID (eg, IGU ID) and/or network controller ID to Specific VSS or specific entity sky sensor. In such cases, these maps can be used to use test and/or simulated data (virtual sky sensor values) from a specific VSS, real data from physical (eg sky) sensors, or virtual and real-world sensing Any combination of instrument data is used to determine whether to run the predictive model for the partition and/or device.

33 is an example of a location management console 3310 according to an aspect . The location management console 3310 is configured to receive user input and interpret the information. For example, location management console 3310 may be configured to receive user input at virtual sky sensor 3314 . The location management console 3310 includes a first section 3320 with lower buttons labeled "Ring Sensors" which, when selected, map sky (ring) sensors to partitions that can be tinted windows Or map to a specific shadeable window. The first section 3320 includes upper buttons labeled "Light Sensors" which, when selected, map the light sensors. In this description, the lower button labeled "Ring Sensor" has been selected. The location management console 3310 includes a second section 3330 for selecting ring sensors to assign to partitions/windows including: 1) "MFST Remote" sensor 3332 , which is A physical sky sensor; or 2) "Foresigh Sensor" sensor 3334 , which is a virtual sky sensor.

In one implementation, sensor data or weather feeds from local sensors are used to determine the control status of a first set of partitions of one or more devices, and virtual sky sensor data is used to determine one or more devices. The control state of the second set of partitions of the plurality of devices. In this case, the first set of partitions are mapped to physical sky sensors, and the second set of partitions are mapped to virtual sky sensors. If sensor data is not available, the weather feed data will be used to determine the control status of the first set of zones. The location management console can be used to map sky sensors to zones.

34 illustrates a quality assurance (QA) or test scenario implementation of a virtual sky sensor according to one aspect. 34 is a schematic diagram of a system 3400 including one or more interactive systems interfaced with each other at a location, according to an aspect. The system 3300 includes a location management console 3410 configured to monitor one or more locations and a virtual sky sensor application 3412 in communication with the location management console 3410 . The location management console 3410 is configured to receive user input and interpret the information. In this example, the location management console 3410 is configured to receive user input including test cases for the test suite including time/date stamps and sensor values. In some cases, the site management console 3410 is an API that can interface with systems external to the site.

The system 3400 includes a main controller 3450 having: a data extractor application 3452 ; a field database 3454 that communicates with the data extractor application 3452 to insert data into the field database 3454 ; control logic 3456 , It has a prediction model in communication with field database 3454 to receive sensor data and send predictions saved to field database 3454 . The field database 3454 may include one or more of a local sensor database, a weather feed database, a forecast database, and a QA test case database. The data extractor application 3452 communicates with the virtual sky sensor 3412 to send requests for data to the virtual sky sensor 3412 and to receive the data. Data extractor application 3452 communicates with data source 3420 to receive local sensor data from local sensors, such as ring sensors, or remote data sources, such as weather feeds, via third-party APIs. end sensor data. In another embodiment, the control logic 3456 further includes a deep neural network (DNN).

Although DNNs are used in the examples described herein, it will be appreciated that other deep learning applications may be used in various implementations.

The system 3400 includes: a first network controller 3462 in communication with a plurality (three) of leaf/terminal controllers of a first partition ("Partition 1") of a control device (eg, a tintable window); and a second A network controller 3464 in communication with a plurality (five) of leaf/terminal controllers of a second partition ("Partition 2") of the control device. In other implementations, fewer or more network controllers, partitions, and leaf/terminal controllers may be used.

In this implementation, time and/or date stamps and sensor values from test cases with multiple conditions in the test suite are provided to the site management console 3410 . Pass this information to VSS 3412 . Data extractor 3452 requests data from VSS 3412 , and data extractor 3452 inserts the data into field database 3454 for consumption by control logic 3456 to determine control commands. Control logic 3456 makes determinations and compares the behavior of the predicted models under various conditions in the test suite. The comparison results can be passed back to the location management console 3410 for user review. Optionally (represented by dashed lines), control instructions based at least in part on the various cases may be communicated to the first network controller 3462 to control partition 1 of the device and to the second network controller 3464 to control partition 2 of the device .

35 illustrates an A/B testing implementation of a virtual sky sensor according to an aspect. 35 includes a schematic diagram of a system 3500 including one or more interactive systems interfaced with each other at a location, according to an aspect. The system 3500 includes a location management console 3510 configured to monitor one or more locations and a virtual sky sensor application 3512 in communication with the location management console 3510 . The location management console 3510 is configured to receive user input and interpret the information. In this example, the location management console 3510 is configured to receive user input including a mapping of the partition's ID and/or device's ID to the virtual sky sensor application 3512 and the partition's ID and/or Or a mapping of the device's ID to a physical sky sensor (or set of sensors) such as a ring sensor in the copied location configuration. In some cases, the site management console 3510 is an API that can interface with systems external to the site.

In another embodiment, the system 3500 uses a virtual sky sensor 3512 or multiple virtual sky sensors to host a predicted/calculated sensor with multiple prediction modules from a replicated location configuration A data set of values to evaluate the performance of the prediction model.

Returning to FIG. 35 , the system 3500 includes a main controller 3550 having: a data extractor application 3552 ; a field database 3554 that communicates with the data extractor application 3552 to insert data into the field database 3554 ; Control logic 3556 has prediction models in communication with field database 3554 to receive sensor data and send predictions saved to field database 3554 . The field database 3554 may include one or more of a local sensor database, a weather feed database, a forecast database, and a Q/A test case database. The data extractor application 3552 communicates with the virtual sky sensor 3512 to send requests for data to the virtual sky sensor 3512 and to receive the data. Data extractor application 3552 communicates with data source 3520 to receive local sensor data from local sensors, such as ring sensors, or remote data sources, such as weather feed data, via third-party APIs. end sensor data. Control logic 3556 includes a deep neural network (DNN) 3558 that generates predictions such as forecasted sensor data and/or forecasted weather conditions. Control logic 3556 communicates with field database 3554 to receive sensor data and insert predictions determined by DNN 3558 into field database 3554 .

The system 3500 includes: a first network controller 3562 in communication with a plurality (three) of leaf/terminal controllers of a first partition ("Partition 1") of a control device (eg, a tintable window); and a second A network controller 3564 in communication with a plurality (five) of leaf/terminal controllers of a second partition ("Partition 2") of the control device. In other implementations, fewer or more network controllers, partitions, and leaf/terminal controllers may be used.

In this implementation, DNN 3558 obtains real-time sensor data communicated from physical sky sensors of data source 3520 , performs predictions, and passes predictions to VSS 3512 . The data extractor 3552 requests data from the VSS 3512 , and the data extractor 3552 inserts the predictions from the DNN 3558 of a replicated site configuration into the field database 3554 . The data extractor 3552 receives sensor data from the data source 3220 and inserts the data into the field database 3554 for another replication site configuration. The control logic uses the data used to replicate the site configuration to determine different sets of control levels, respectively. Control logic 3456 compares the control level associated with the data from the predictive model with the control level associated with actual sensor data from data source 3220 . The data comparison result is passed back to the location management console 3410 for the user to view. Optionally (represented by dashed lines), control commands based at least in part on one of these sets of control levels may be communicated to the first network controller 3562 to control partition 1 of the device and to the second network control Controller 3564 to control partition 2 of the device.

36 illustrates sensor readings detected by a physical ring sensor, predicted and/or predicted sensor values determined by DNN, and use of predicted and/or predicted sensor values determined by DNN by control logic, according to one aspect Or a graph of the hue level determined by the predicted sensor value. This is an example of the results of an A/B evaluation.

Certain aspects relate to building specialized forecasting models using training data representing distinct weather conditions and/or selecting specific specialized forecasting models for immediate (real-time) deployment when representative weather conditions occur. These specialized weather models can be constructed in a "supervised" and/or "unsupervised" manner. In embodiments where specialized weather models are built in an "unsupervised" fashion, machine learning programs can be used to cluster similar day-length radiation profiles into quantitatively distinct weather types. In implementations where ad hoc weather models are built in a "supervised" fashion, ad hoc prediction models can be trained on data for which quantitative classifications already exist, for example by utilizing data available through third-party APIs. Some examples of existing classifications and/or conditions include sunny conditions or "sunny", partly cloudy conditions or "partly cloudy", foggy conditions or "fog", rain conditions or "rain", hail conditions or "hail", storms Conditions or "storms", or smog conditions or "smokes". The performance of these specialized models can be optimized for these weather conditions. Specialized forecasting models may be deployed for real-time forecasting within days when the corresponding conditions have been met or forecasted (eg, as sensed by sensors), eg, in weather feeds from third-party APIs. Such specialized predictive models may benefit from specialized curriculum learning of the pattern properties of at least one (eg, each) condition.

In some implementations, specialized weather models are built in an "unsupervised" fashion. Machine learning programs can be used to cluster similar day-length radiation profiles into quantitatively distinct weather types. An example of an unsupervised classifier module that can be used is module E shown in FIG. 25 . In this case, unsupervised clustering methods are used to identify different weather profiles from the data, and to train and deploy models for different kinds of weather. For example, building specialized weather models in an "unsupervised" manner can be used, such as when weather feed data cannot be accessed from a third-party API. Some unsupervised methods to develop a curriculum of weather types for learning may be computationally more expensive and more data-intensive than some supervised methods because such unsupervised methods: (1) represent distinct classes of identified The longer history of the condition range; and (2) the work of subject matter experts to determine whether the quantitative distinctions made are qualitatively valid. Examples of unsupervised clustering algorithms that can be used in various combinations include: k-means clustering, Hidden Markov models, PCA, t-distributed Stochastic Neighbor Embedding (t-SNE), and the like .

In some embodiments, specialized weather models are built in a "supervised" fashion. For example, a "supervised" approach to building specialized weather models can be used, where weather feed data can be accessed from one or more third-party APIs and persisted on a database. In this case, specialized predictive models are trained on data for which qualitative classifications already exist by utilizing data available through third-party APIs. Models can be trained on data associated with weather conditions, and then specialized models trained for specific weather conditions can be deployed when weather conditions are forecast. In some cases, utilizing a third-party AP1 to supervise training a model optimized for performance on pre-labeled training data can eliminate (1) "cold-start" problems (eg, insufficient data available) and/or (2) The need for human intervention during model curation. Examples of supervised models that can be used in various combinations include: multilayer perceptrons, decision trees, regression (eg, logistic regression, linear regression, and the like), SVM, Naive Bayes, and the like. In some implementations, unsupervised clustering can be combined with specialized weather models built in a "supervised" fashion. In one example, a clustering algorithm may be used to reduce the dimension of the feature space of the training set used to train the supervised model in order to reduce the variance of the supervised model.

According to some aspects, the control logic may generate training data in a supervised manner using historical sensor data retained in a database and weather forecasts received from third-party APIs over time. For example, weather forecasts may be received in incremental time periods (eg, within a day, within an hour, within a minute, etc.). The system can divide historical sensor data stored into the database according to these time periods, and tag the sensor data with the corresponding weather conditions for that time period provided in the weather feed from the third-party API (indexed). ). Sensor data tagged with weather conditions can be used as training data for specialized prediction models.

As an example, the control logic may store historical sensor data from a physical sky sensor (eg, a ring sensor, such as a rooftop unit, with an infrared sensor and a light sensor) over a period of one hour (one reading per minute) is stored in the database. During this hour, "sunny" weather conditions can be received in weather feeds from third-party APIs. In this example, the control logic marks each sensor data with readings taken during that hour as "sunny." The control logic can generate training data that can be used to train specialized weather models for "sunny" weather conditions using sensor data labeled "sunny" (or identified by "sunny"), including Marked data obtained during that hour. The control logic may generate other training data sets for training other specialized weather models for other weather conditions such as "rainy", "stormy" using sensor data already tagged with other corresponding weather conditions in the database.

In one embodiment, at least two specialized prediction models for particular weather conditions are built in each of a supervised and unsupervised manner, eg, to compare results and/or verify one or both to be available for deployment Model.

In certain implementations, pre-trained specialized predictive models are deployed on-the-fly using a real-time model selection framework such as described herein. For example, if a third-party API forecasts mixed weather conditions for the next day, the real-time model selection framework of the forecast module can be used to deploy the corresponding pre-trained specialized weather model at the time index specified by the forecast. 27A presents an example of a flow diagram illustrating a dynamic model selection method that can be used to determine pre-trained specialized predictive models for deployment and when to deploy. For example, operation 2907 of the flowchart may further include selecting a specialized forecast model at the index specified by the forecast in the weather feed from the third-party API. Selected pre-trained specialized weather models can be deployed at the time index specified by the forecast.

In certain implementations, a pre-trained specialized predictive model is deployed using a real-time model selection framework (eg, the method in FIG. 27A ) based at least in part on a supervised deployment framework to deploy specialized predictive models that have been supervised . Unlike some unsupervised methods of real-time model selection, a supervised deployment architecture may reduce (eg, avoid) the additional computational overhead and/or involved in identifying the occurrence of quantitatively distinct sensor radiation patterns, eg, at the execution stage time. Using a supervised approach leverages third-party information to drive curriculum development for the range of weather conditions for which dissimilar prediction models can be learned, transferred, and/or efficiently deployed.

In one embodiment, specialized predictive models are built in both supervised and unsupervised ways. A model selection framework can be used to identify (eg, in advance) which of these specialized predictive models to deploy. Selection may involve using, for example, an efficacy measure to determine whether to use a supervised-built specialized predictive model and/or an unsupervised built specialized predictive model. The advantage of unsupervised training of a model is that it allows the data (e.g. unique hyperlocal weather conditions) to define the most appropriate "weather type" by itself. The advantage of a supervised model is to save the computational cost involved in having those "weather types" provided by third-party APIs as out-of-the-box tags. In the case of an unsupervised model, a quantitative measure will determine when weather conditions change to warrant deployment of different models (eg, applying a pretrained time series classifier to a rolling window of sensor data every 30 minutes to quantify self- The "distance" (Euclidean, Cosine, Dynamic Time Warp, and/or the like) between the 30-minute prototype template of weather conditions and the sensor values of the currently observed template. Deploy the model corresponding to its classification ). In the case of supervised models, we can rely on the accuracy of 3rd party forecasts to decide when to deploy different models.

When a minimum number of day-length data frames (eg, 7 days) of historical data that can be paired with corresponding weather markers (eg, provided by a third-party API) have been accumulated, a specialized prediction model may be initialized. In some cases, historical data may be stored in off-site storage, such as cloud storage, and/or persisted on an on-site database (eg, for a specified period of time (eg, 10 days)). If the minimum amount of historical data is not available in off-site storage, the retention on the on-site database may be extended (eg, by 30 days) to support initialization in some cases.

In some embodiments, sensor inputs obtained from physical (eg, sky) sensors at at least one (eg, each) location and/or weather feeds from physical parts corresponding to locations are used The data-derived training data initializes a specialized prediction model for that location. In some cases, sensor input from a physical (eg, sky) sensor at another location (eg, a nearby location) and weather feed data applicable to another (eg, nearby) location may be used to initialize Specialized predictive models at other locations, such as those in close proximity. Sensor input and/or weather feed data from another (eg, nearby) location can augment the queue of training data for at least one (eg, each) category at the other location. A specialized prediction model initialized for another (eg, nearby) location can be used as a pretrained model for a different location (eg, for a new debug location with an empty sensor data queue). An initialized ad hoc model can create a class template for at least one (eg, each) weather condition under which the (eg, nightly) transfer learning procedure yields as additional days reveal its own weather conditions. Improving the transfer can occur during low occupancy periods of the location (eg, as disclosed herein).

The specialized predictive model may be retrained periodically (eg, daily or on some other periodic basis (eg, between every 1 and every 10 days)). In certain embodiments, the ad hoc predictive model may be retrained at times when the real-time model is not being executed (eg, during periods of low occupancy, such as sometime during the night, such as at midnight). The model can be retrained on data (sensor data and/or weather feed data) that has been updated since the last training. To receive weather feeds from a third-party API, requests can be made to the third-party API at the start of training (eg, at midnight) and at the end of predictions (eg, at sunset). Weather feed data can be attached to the Recent Day Length data frame for the corresponding training queue for its weather category. Weather feeds can be used to identify appropriate specialized weather models for deployment, such as during the next day's real-time forecast.

In some embodiments, the network is operatively (eg, communicatively) coupled to at least one forecast (eg, forecast) module (eg, external condition forecasts such as disclosed herein). The forecasting module may process data (or direct processing data) from one or more controllers (eg, of a hierarchical control system). The forecasting module can predict (or guide forecasting) light sensor, infrared (IR) and/or temperature sensor data. The light sensor can be configured to sense one or more wavelengths (eg, one or more wavelengths in the visible spectrum) that the average person is sensitive to. The light sensor can be configured to sense infrared and/or ultraviolet radiation. The prediction module may be used to predict and/or accelerate the hue transition of the tintable window, such as by accelerating shading commands (eg, darkening and/or lightening the tintable window). The prediction module may utilize statistical post-processing applied to the sensor data. The sensor data may belong to any sensor disclosed herein (eg, a sky sensor). The sensor may be a virtual sensor (eg, a virtual sky sensor). The sensor may be a combined sensor. An example of a combined sensor can be found in US Patent Application Serial No. 15/514,480, filed March 24, 2017, entitled "COMBI-SENSOR SYSTEMS" (now filed on January 21, 2020) U.S. Patent No. 10,539,456 issued today), which application is incorporated herein by reference in its entirety. The virtual sensor may use measurements from one or more adjacent sensors for at least one portion of the lacking sensor to predict one or more characteristics in that portion, the one or more adjacent sensors sensing one or more properties. A virtual sensor may be implemented in a (eg, non-transitory) computer-readable medium. The virtual sensor may include logic to predict the absence of sensor readings in one or more locations of the sensor. The forecast module may include logic to forecast one or more properties sensed by the sensors. The forecasting module may reduce bias and/or variance in processing sensor data and forming forecasts.

In some embodiments, predictions for the modules disclosed herein are (1) generated using input from (eg, sky) sensors and/or weather forecasts (eg, 3rd party weather APIs), and (2) ) is stored on the database (for example, on the main controller). In some embodiments, the modules disclosed herein provide automated model governance over at least a portion (eg, the entire) life cycle of an application, eg, to increase transfer learning to successfully continue and/or to enable the module to adapt to subsequent Probability of time-altered weather conditions. In some embodiments, a (eg, autonomous) learning system that includes modules benefits from at least minimal guidance on criteria including (1) what the learning system learns; 2) how the learning system learns; and 3) learning The system is learning.

In some embodiments, a learning system (eg, including a VSS) learns, eg, artificial intelligence (eg, neural network) model parameters that minimize prediction error. In some embodiments, the learning system performs its learning at least in part by using hyperparameters. Example hyperparameters that can be tuned include: number of hidden layers, dropout rate indicating the percentage of neurons removed during each epoch to prevent overfitting, selected firing function, weight initialization, or any combination thereof. Hyperparameter learning determines, at least in part, how the learning system achieves its optimal model parameterization, eg, the path the learning system takes to achieve that optimal. In some embodiments, what the learning system is learning relates to model management functionality provided by the learning system (eg, including the modules disclosed herein). In some embodiments, to provide this functionality, the learning system interprets potential model bias events that are flagged during prediction post-processing.

In some embodiments, model bias occurs at least when (1) training is interrupted by a platform failure and/or (2) the operation to perform the training is removed by the user (eg, by mistake and/or inadvertently). This failure can affect the training and/or retraining of the learning system. Learning may be performed during periods of low occupancy for a location (eg, as disclosed herein), such as at night. The user may be remotely serving part of the control system. The control system portion may be where the database and/or modules reside and/or operate (eg, at the main controller). Failure to train and/or retrain can affect model quality and can introduce bias, for example because (eg, nightly) training keeps the learning system up to date as weather conditions change.

Model bias can be quantified (eg, on-the-fly) during post-processing. Deviation detection can occur in several ways, such as by comparing a predicted value with a value that eventually occurs (eg, as sensed by a real-world sensor). The model deviation can be the sensor value predicted at time t (eg, predicted by a modeled system such as VSS before time t) and the value actually sensed by the real entity sensor at time t (once that time arrives) difference between. In some embodiments, the health monitor (including the VSS) predicts light sensor and/or IR sensor values for each time increment (eg, minute) to speed up shading commands for shading windows. The VSS may predict sensor data based at least in part on data used to control one or more systems (eg, window control systems) at the site. The health monitor may be referred to herein as a "Foresight Health Monitor" or "Foresight".

In some embodiments, model deviations are found once there is a difference between the predicted value and the actual measured value that exceeds a threshold value. Model bias can be quantified by tracking the difference between: (i) the predictions of the learning system (eg, using VSS); and (i) preset roll-metric sensor values (eg, determined by a system such as a solid sky) physical sensor measurements of the sensor set). The physical sensor values are fed into the network and utilized by the control system to, for example, change the hue of the tintable window. The rolling physical sensor measurements may be rolled over a time period (eg, any of the time periods disclosed herein), such as every about t (eg, about 10 minutes) time period. A plurality of consecutive sensor values may be represented by a single sensor value that is the mean/average/median value of the plurality of consecutive sensor values. For example, sensor values acquired over a period of time (eg, 10 minutes) can be used for this mean/mean/median calculation. The sensor may include a light sensor or an IR sensor (or any other sensor disclosed herein).

In some embodiments, the difference (eg, delta, offset) between the sensor value predicted by the learning system and the physical sensor value during time "t" is greater than a threshold value (eg, by The deviation control is automatically and/or manually set by the user), resulting in an unhealthy first deviation. Threshold values can contain values or functions. Functions may be time and/or space dependent. The function may depend on the sensor type. The learning system (eg, via its database, such as a log file) may facilitate identifying (eg, flagging) the predicted value at "t" as a potential model bias event (eg, using the virtual sensor data it generates) any timestamp). A learning system (eg, a health monitor module) can track any continuous deviations from the identified deviations at time "t" (eg, before or after comparing to a threshold value and finding it to be a healthy/unhealthy deviation). If the duration of the deviation is greater than the duration threshold and if the deviation is greater than the deviation threshold (eg, flag it as an "unhealthy" deviation), the health monitor may log and/or notify the unhealthy deviation (eg, with initial remedy).

In some embodiments, the learning system operates during low occupancy periods in the location (eg, nightly). The learning system may analyze (eg, dissect) VSS data (eg, embodied in log files) for such minute-level deviation events. When any such event occurs over a long period of time (eg, longer than "t", eg, t is 10 minutes, and the longer period is one hour), the health monitor module can detect the time frame in which a deviation event will occur . The deviation module may record or otherwise indicate the "unhealthy" status of deviation events in the learning system. For example, a deviation module may update (eg, in a table) "unhealthy" deviation events on a (eg, dedicated) database. The database may belong to a control system (eg, a master controller). The database may be stored in the processor of the occupancy and/or operational deviation module. The database can be stored in a processor that does not occupy and/or operate the deviation module. The deviation module platform can (eg, automatically) alert and/or report an "unhealthy" state, eg, so that it can be quickly resolved. Reports may be made to site managers, service groups, owners, users and/or the like. The deviation module may be part of the health monitor module and is operatively (eg, communicatively) coupled to (eg, and operating in conjunction with) the health monitor module.

Deviation modules can be configured to deliver timely (eg, minute-level) control either in real-time (eg, at the execution stage in a real-time forecast setting) or non-real-time. The health monitor may track the duration and/or persistence of any deviation event, eg, periodically (eg, daily). Tracking deviation events may provide module control over at least a portion (eg, the entire) lifecycle of health monitor operations (eg, and other module operations). Modular governance can increase the chances (eg, ensure) that transfer learning continues successfully and that the learning system adapts to changing weather conditions over time.

In some embodiments, during the execution phase, the deviation trigger returns the sensor value predicted by the weather prediction module (eg, VSS) within that minute. Isolated deviation triggers may reflect the slow response of the weather forecasting module to, for example, rapidly changing weather. Persistent bias triggers over a time span can interfere (e.g., nightly) with model retraining.

37 shows an example of a flowchart 3700 depicting the operation of the health monitor and deviation model. In block 3701 , sensor data (eg, VSS sensor data) is processed. For example, light sensor data may have a string of light sensor identifiers, and an IR sensor may have a string of IR identifiers. Sensor data can be stored in a database (eg, as a log file). Analysis may require extraction of stored data. In block 3702 , the sensor data is identified, eg, by sensor type and packaged according to sensor type and/or time, as appropriate. For example, light sensor and IR sensor data and/or their respective timestamp information are identified. Timestamp information may include the start and/or end of sensor measurements. In block 3703 , deviation data is identified (eg, by comparison to default sensor data). Data can be split into (eg, consecutively occurring) deviation events. In block 3704 , the deviation data is compared to a threshold value and classified as "healthy" or "unhealthy." The health flag can be a binary flag (eg, 1 for "healthy" and 0 for "unhealthy"). In blocks 3705 and 3706 , the timestamps of the deviation data are analyzed to find events that persist beyond a time window (eg, lasting more than 1 hour), eg, to find "unhealthy" continuous measurements that persist beyond a time threshold Bias data. The time threshold may be the same for at least two data types (eg, light sensors and IR sensors). The time thresholds may be different for at least two data types (eg, light sensors and IR sensors). For example, the time threshold for light sensor bias may be 60 minutes, and the time window for IR sensor bias may be 70 minutes. In block 3707 , a health monitor database (eg, table) is updated with at least two of (i) deviation-related information, (ii) health flags, and (iii) associated timestamps.

In some embodiments, one or more benefits of a module disclosed herein (eg, a health monitor module) can be quantified (eg, in a quantified module). Quantifying module benefits can facilitate accelerated tone decisions. For example, quantification may allow knowing any gain in sunlight and/or glare protection. For example, by comparing some modules to others. For example, combine data from modules A, B, C, and/or C1 (eg, regarding hue-based decisions) with data from health monitors and/or VSS modules (eg, regarding hue-based decisions) Compare. The health monitor module may be referred to herein as the "Foresight Health Monitor" or "Foresight". The quantification module may be referred to herein as the "Foresight Analysis Module". Smart modules may include modules A, B, C, C1, D, and/or D1, eg, as disclosed herein. Foresight modules may include learning modules, health monitor modules, and/or VSS modules, eg, as disclosed herein.

In some embodiments, the quantification module may quantify the amount of additional glare protection and/or additional daylight provided to facility occupants by utilizing either module, including its logic, variables, methods, and/or thresholds .

In some embodiments, the verification module is configured to compare (eg, quantifiably) the smart module tint command with the Foresight tint command. It can be directly obtained from the output of the smart module or can be regenerated by the quantization module to the smart module tone command. For example, the quantization module may (I) use the hue command generated by the smart module or (II) by using sensor data (eg, as used by the smart module), the smart module analysis scheme and/or the smart module Mod threshold to regenerate smart mod tint commands. In some embodiments, learning modules (eg, Foresight health monitors) and/or quantification modules are configured to perform one or more operations (eg, protocols or logic). In some embodiments, the verification module may perform one or more operations of a smart module (eg, smart control logic), such as to evaluate smart tone commands (eg, by comparing them with respective Foresight commands) Compare).

38 shows an example of a flowchart 3800 depicting the operation of the quantization module . In block 3801 , physical sensor data is received (eg, directly from the sensor or via a smart module). In block 3802 , the sensor data is analyzed using logic in the respective smart module (eg, including any thresholds) to output ( 3807 ) a first hue command (eg, receive a first timestamp). Output 3807 can come directly from a smart module (not shown). In block 3803 , virtual sensor data is received (eg, directly from the VSS or via the Foresight module). In block 3804 , the virtual sensor data is analyzed using logic in the respective Foresight module (eg, including any thresholds) to output ( 3808 ) a second tone command (eg, receive a second timestamp). The output 3808 can come directly from the smart module (not shown). In block 3805 , the hue commands and/or timestamps are compared (eg, quantitatively) to produce a result. In block 3806 , results are identified and/or output, eg, when there is a change (eg, including a change in timestamp) between the first hue command and the second hue command. The comparison may be against threshold values (eg, time threshold value, hue threshold value). This change may contribute to gains in sunlight and/or glare protection for users in the facility. The output can depend on the gain of sunlight and/or glare protection.

In some embodiments, the verification module uses (i) the raw data provided to the smart module and/or (ii) the processing scheme (eg, logic) of one or more smart modules to regenerate the smart module's value. For example, the verification module may use raw (eg, light sensor or IR) physical sensor data (eg, tail) and/or processing schemes (eg, logic) of one or more smart modules to Regenerates the wisdom module value. The quantification module can utilize thresholds (eg, light sensors or IR) for sensor measurement analysis by one or more smart modules (eg, smart modules C/C1 or D/D1 ). For example, its parameters), to regenerate the respective intelligence module commands. The Foresight module tint command can be obtained directly from the Foresight output or regenerated by the quantization module. Foresight tint commands may utilize virtual composite sensor data (eg, VSS data) and inputs and Foresight logic for generating tint commands.

In some embodiments, the quantization module may utilize sensor data. For example, the quantization module may include light sensor and/or IR sensor data. The quantization module can utilize partition-related data. A partition may contain multiple windows with the same geographic location, placed on the same floor, on the same facade of a facility (eg, a building), with the same room type (eg, a meeting room, office, or cafeteria) or The same degree of occupancy (eg, assigned for rooms with 10 or less occupants, between 10 and 100 occupants, and 100 and more occupants). The level of occupancy can be actual (eg, entered using an occupancy sensor or and ID tag) or predicted (eg, estimated dates and/or hourly schedules for using the facility). The quantification module may utilize sensor value predictions (eg, using a health monitor module, a VSS module, and/or any other prediction module disclosed herein (eg, using artificial intelligence)). The quantification module may utilize one or more thresholds (eg, thresholds), such as utilized by either an intelligence module or a Foresight module.

In some embodiments, the quantification module performs analysis (eg, including one or more calculations). Analysis may include using physical sensor data (eg, using light sensor and/or IR sensor values) to calculate for smart modules (eg, module C (or C1 ) and module D (or D1 ) ) for one or more of the hue commands. The data for the tint command may be computed for windows placed in the partitions (eg, listed in a table or otherwise associated with the partitions). Analysis may include deriving sensor time information (eg, time stamps measured by the sensor) for a specified time range (eg, morning and night or day and night). Analyzing may include assigning module C values based at least in part on threshold values (eg, threshold parameters (eg, one or more threshold parameters) of modules A, B, C, C1, D, and/or D1 ) To the non-tail data area and assign the module D (or D1) value to the tail data area. Smart modules may include modules A, B, C, C1, D and/or D1. Analysis may include regenerating one or more smart module values using raw sensor data (eg, light sensor measurements and/or IR measurements) acquired by real physical sensors. In some embodiments, the quantization module is configured to receive and/or acquire (eg, load) raw sensor measurements (eg, from a light sensor). Sensor data may belong to a plurality of sensors (eg, at least 2, 4, 6, 8, 10, 12, or 13 sensors). The sensor data may come from a sensor in a sensor set (eg, a real-world sky sensor). Sensor values from a plurality of sensors may be filtered. Filtering can utilize rectangular wave filtering. Rectangular waves may include short rectangular waves or long rectangular waves. Filtering can include high-pass or low-pass filters. Analysis may include calculating mean/median/mean values assigned to the plurality of light sensors. A plurality of light sensors may be arranged in a single row (eg, arranged on a curve such as a circle or ellipse or portions thereof). At least one of the plurality of (eg, light) sensors may be placed in the exterior of a facility (eg, a building), such as on a roof of a building or attached to a building facade. Filtering may include filtering measurements taken during the time range. The time frame may be at least about 5 minutes (min.), 10 minutes, 15 minutes, 20 minutes, 40 minutes, 60 minutes, or 80 minutes. The time range may be up to about 2 minutes, minutes, 10 minutes, 15 minutes, 20 minutes, 40 minutes, 60 minutes, or 70 minutes. The time frame can be any of the time frames disclosed herein. Sensor values are measured at time intervals (eg, frequency) at most about every 0.25 minutes, 0.5 minutes, 1 minute, 2.5 minutes, 5 minutes, or 7.5 minutes. The tint command may be issued at intervals (eg, frequency) at most about every 2.5 minutes, 5 minutes, 7.5 minutes, 10 minutes, 15 minutes, 20 minutes, 30 minutes. Hue commands may be issued at intervals (eg, frequency) that are at least about 2.5*, 5*, 7.5*, or 10* slower than the sensor measurement interval (eg, sensor measurement frequency). The symbol "*" indicates the mathematical operation "multiplication".

In some embodiments, the quantization module distinguishes the type of hue transition (eg, from light to dark or dark to light; from less tinted to more tinted or from more tinted to less tinted). In some embodiments, the quantization module analyzes hue transitions, such as from light to dark (eg, from less tint to more tint). Module C (and/or C1 ) may be configured, for example, to make determinations about target hue values (eg, based at least in part (eg, only) on sensor measurements (eg, as disclosed herein) recommendations) decisions. Smart modules (eg, module C or C1) color tone decision. Hue decisions can be assigned to day timeframes (which may be referred to as "non-tail" timeframes). The morning or evening time range may be referred to as the "tail" time range.

In some embodiments, the inspection module uses raw (eg, light sensor or IR) physical sensor data (eg, "tail" data collected during morning or evening time frames) and/or one or more A smart module's processing scheme (eg, logic) to regenerate the smart module's value. Threshold values (eg, parameters thereof) for use by one or more smart modules for (eg, light sensor or IR) sensor measurement analysis can be assigned (eg, to smart modules C/C1 or D) /D1).

In some embodiments, the quantization module regenerates the smart module processing scheme. For example, the inspection module may perform a mid-tone (eg, tint) between a lower tone level and a higher (eg, darker) tone level (such as between the transition of Hue 2 and Darker Hue 4). 3) A command that is derived from the module C (or C1) output and receives a timestamp when it is executed. The locking time range of module C (or C1 ) may be implemented for each such mid-tone (eg, hue 3) decision. Cycles according to smart commands, at intervals (eg, of 2, 5, 7, or 10 minutes) tonal decisions and self-sensors derived from values in a data table (eg, from the Foresight health module) (e.g., directly or via a smart module) for comparison of hue decisions. The solar gain and/or glare protection gain caused by any changing (eg, accelerated) Foresight decision can be calculated, for example, by comparing the time stamps when the smart tint command was issued and the Foresight health monitor module tint command. This timestamp comparison may also reveal any delayed Foresight decisions (eg, prompting revisions and/or evaluations of Foresight module logic). In a timely (eg, daily) manner, sunlight and/or delivered by the predicted sensor values of the Foresight health monitor module (eg, the predicted light sensor and/or IR sensor of the VSS) The glare protection gain (eg, in minutes) may be updated in and/or stored in a (eg, dedicated) table in a (eg, dedicated) database.

It should be understood that control logic and other logic to implement the techniques described herein may be implemented in the form of circuits, processors (including microprocessors, digital signal processors, application-specific integrated circuits, such as field programmable logic of programmable gate arrays, etc.), computers, computer software, devices such as sensors, or combinations thereof.

Any of the software components or functions described in this application can be implemented as code to be executed by a processor using any suitable computer language such as Java, C++ or Python using, for example, conventional or object-oriented techniques . The code may be stored as a series of instructions or commands on a computer readable medium such as random access memory (RAM), read only memory (ROM), programmable memory (EEPROM), hardware such as Disk drives or soft magnetic media or optical media such as CD-ROMs. Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices within a system or network.

Additionally, although the present disclosure discloses the use of certain types of recurrent neural networks, other neural network architectures are used for short-term and/or longer-term prediction of environmental conditions, such as, but not limited to, those known to those skilled in the art. Multilayer Perception (RMLP), Gated Recurrent Unit (GRU) and Temporal Convolutional Neural Network (TCNN) architectures.

While the previously disclosed embodiments for controlling lighting received through a window or inside a building have been described in the context of optically switchable windows such as electrochromic windows, one can appreciate how the methods described herein may be implemented On the appropriate controls to adjust the position of the shades, blinds, blinds, or any other device that can be adjusted to limit or block light from reaching the interior spaces of the building. In some cases, the methods described herein can be used to control both the tint of one or more optically switchable windows and the position of the shading device. All such combinations are intended to be within the scope of this disclosure.

One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present disclosure. In addition, modifications, additions, or omissions may be made to any embodiments without departing from the scope of the present disclosure. The components and modules of any embodiment may be integrated or separated according to particular needs without departing from the scope of this disclosure.

Accordingly, while the foregoing disclosed embodiments have been described in considerable detail to facilitate understanding, the described embodiments are to be regarded as illustrative and not restrictive. It will be apparent to one of ordinary skill in the art that certain changes and modifications can be practiced within the scope of the appended claims.

In some embodiments, the sensor is operatively coupled to at least one controller and/or processor. Sensor readings may be obtained by one or more processors and/or controllers. A controller may include a processing unit (eg, a CPU or GPU). The controller can receive input (eg, from at least one sensor). The controller may include circuitry, electrical wiring, optical wiring, communication terminals and/or sockets. The controller can deliver output. A controller can contain multiple (eg, sub) controllers. The controller may be part of a control system. The control system can include a main controller, a floor (eg, including a network controller) controller, or a local controller. The local controller may be a window controller (eg, controlling an optically switchable window), an enclosure controller, and/or a component controller. The controller may be a device controller (eg, any of the devices disclosed herein, such as a sensor or transmitter). For example, a controller may be a hierarchical control system (eg, including a master controller that directs one or more controllers, such as floor controllers, local controllers (eg, window controllers), closed body controller and/or component controller). The physical part of the controller type in a hierarchical control system may be changing. For example, at the first time: the first processor can assume the role of the main controller, the second processor can assume the role of the floor controller, and the third processor can assume the role of the local controller; in the second Time: the second processor can assume the role of the main controller, the first processor can assume the role of the floor controller, and the third processor can maintain the role of the local controller; and at the third time: the third processor It can assume the role of the main controller, the second processor can assume the role of the floor controller, and the first processor can assume the role of the local controller. The controller may control one or more devices (eg, directly coupled (eg, connected) to the devices). A controller may be positioned proximate to one or more devices it is controlling. For example, the controller may control optically switchable devices (eg, IGUs), antennas, sensors, and/or output devices (eg, light sources, sound sources, odor sources, gas sources, HVAC outlets, or heaters). In one embodiment, a floor controller may direct one or more window controllers, one or more enclosure controllers, one or more component controllers, or any combination thereof. Floor controllers may include floor controllers. For example, a floor (eg, including a network) controller may control a plurality of local (eg, including a window) controller. A plurality of local controllers may be located in a portion of a facility (eg, in a portion of a building). This part of the facility may be the floor of the facility. For example, floor controllers can be assigned to floors. In some embodiments, a floor may include a plurality of floor controllers, eg, depending on the floor size and/or the number of local controllers coupled to the floor controllers. For example, a floor controller can be assigned to a portion of a floor. For example, a floor controller can be assigned to a portion of the local controllers located in the facility. For example, a floor controller can be assigned to a portion of a floor of a facility. The main controller can be coupled to one or more floor controllers. Floor controllers can be placed in the facility. The main controller may be located in the facility or located outside the facility. The main controller can be located in the cloud. The controller may be part of or operatively coupled to the building management system. The controller can receive one or more inputs. The controller can generate one or more outputs. The controller can be a single-input single-output controller (SISO) or a multiple-input multiple-output controller (MIMO). The controller can interpret the received input signal. The controller may obtain data from one or more components (eg, sensors). Acquiring can include receiving or extracting. Data may include measurements, estimates, determinations, generation, or any combination thereof. The controller may include feedback control. The controller may include feedforward control. Control may include on-off control, proportional control, proportional-integral (PI) control, or proportional-integral-derivative (PID) control. Control can include open loop control or closed loop control. The controller may contain closed loop control. The controller may contain open loop control. The controller may include a user interface. The user interface may include (or be operatively coupled to) a keyboard, keypad, mouse, touch screen, microphone, speech recognition package, camera, imaging system, or any combination thereof. Output can include a display (eg, a screen), speakers, or a printer. 39 shows an example of a control system architecture 3900 that includes a master controller 3908 that controls a floor controller 3906 , which in turn controls a local controller 3904 . In some embodiments, the local controller controls one or more IGUs, one or more sensors, one or more output devices (eg, one or more transmitters), or any combination thereof. 39 shows an example of a configuration in which a master controller is operatively coupled (eg, wirelessly and/or wired) to a building management system (BMS) 3924 and database 3920 . Arrows in Fig. 39 indicate communication paths. The controller is operatively coupled (eg, directly/indirectly and/or wired and/wirelessly) to the external source 3910 . External sources can include networks. The external source may include one or more sensors or output devices. External sources may include cloud-based applications and/or databases. Communication may be wired and/or wireless. External sources may be located outside the facility. For example, the external source may include one or more sensors and/or antennas disposed on, for example, a wall or ceiling of a facility. Communication can be one-way or two-way. In the example shown in Figure 39 , all communication arrows are intended to be bidirectional.

A controller may monitor and/or direct (eg, physical) changes to the operating conditions of the apparatus, software, and/or methods described herein. Control may include regulating, manipulating, limiting, directing, monitoring, adjusting, modulating, changing, altering, restraining, checking, directing or managing. Controlling (eg, by a controller) may include attenuating, modulating, varying, managing, suppressing, discipline, regulating, constraining, supervising, manipulating, and/or directing. Controlling may include controlling a control variable (eg, temperature, power, voltage, and/or profile). Control can include instant or offline control. Calculations utilized by the controller can be performed in real-time and/or offline. The controller can be manual or non-manual. The controller may be an automatic controller. The controller can operate on request. The controller may be a programmable controller. The controller can be programmed.

The methods, systems and/or apparatus described herein may include a control system. The control system can communicate with any of the devices described herein (eg, sensors and/or tintable windows). The devices may be of the same type or of different types, eg, as described herein. For example, the control system may communicate with the first sensor and/or the second sensor. The control system can control one or more sensors. The control system may control one or more components of the building management system (eg, lighting, security and/or air conditioning systems). The controller can adjust at least one (eg, environmental) characteristic of the enclosure. The control system may use any component of the building management system to regulate the enclosure environment. For example, the control system may regulate the energy supplied by the heating element and/or the cooling element. For example, the control system may regulate the speed of air flowing to and/or from the enclosure through the vent. The control system may include a processor. The processor may be a processing unit. The controller may include a processing unit. The processing unit may be a central processing unit. The processing unit may include a central processing unit (abbreviated herein as "CPU"). The processing unit may be a graphics processing unit (abbreviated herein as "GPU"). A controller or control mechanism (eg, including a computer system) can be programmed to implement one or more of the methods of the present disclosure. A processor can be programmed to implement the methods of the present disclosure. A controller may control at least one component forming the systems and/or apparatus disclosed herein.

40 shows a schematic example of a computer system 4000 programmed or otherwise configured to perform one or more operations of any of the methods provided herein. The computer system may control (eg, direct, monitor, and/or regulate) various features of the methods, apparatus, and systems of the present disclosure, such as controlling heating, cooling, lighting, ventilation, or any combination of the enclosures. The computer system may be part of, or in communication with, any sensor or set of sensors disclosed herein. A computer may be coupled to one or more of the mechanisms disclosed herein and/or any portion thereof. For example, a computer may be coupled to one or more sensors, valves, switches, lights, windows (eg, IGUs), motors, pumps, optical components, or any combination thereof.

A computer system may include a processing unit (eg, 4006 ) ("processor", "computer" and "computer processor" are also used herein). A computer system may include memory or parts of memory (eg, 4002 ) (eg, random access memory, read-only memory, flash memory), electronic storage units (eg, 4004 ) (eg, hard disks), Communication interfaces (eg, 4003 ) (eg, network adapters) for communicating with one or more other systems, and peripheral devices (eg, 4005 ) such as cache, other memory, data storage and/or electronic display adapter. In the example shown in Figure 40 , memory 4002 , storage unit 4004 , interface 4003 , and peripherals 4005 communicate with processing unit 4006 via a communication bus (solid line) such as a motherboard. The storage unit may be a data storage unit (or data repository) for storing data. The computer system may be operatively coupled to a computer network ("network") (eg, 4001 ) by means of a communication interface. A network can be the Internet, an Internet and/or an inter-enterprise network, or a corporate intranet and/or an inter-enterprise network that communicates with the Internet. In some cases, the network is a telecommunications and/or data network. The network may include one or more computer servers that may enable decentralized computing, such as cloud computing. In some cases, a network may implement a peer-to-peer network with the aid of a computer system, which may enable devices coupled to the computer system to act as clients or servers.

The processing unit can execute a sequence of machine-readable instructions that can be embodied in a program or software. These instructions may be stored in a memory location such as memory 4002 . The instructions can be directed to a processing unit, which can then be programmed or otherwise configured to implement the methods of the present disclosure. Examples of operations performed by a processing unit may include fetching, decoding, executing, and writing back. The processing unit may interpret and/or execute the instructions. Processors may include microprocessors, data processors, central processing units (CPUs), graphics processing units (GPUs), system-on-chips (SOCs), co-processors, network processors, application-specific integrated circuits (ASICs) , Application Specific Instruction Set Processor (ASIP), Controller, Programmable Logic Device (PLD), Chipset, Field Programmable Gate Array (FPGA) or any combination or plural thereof. The processing unit may be part of a circuit such as an integrated circuit. One or more of the other components of system 4000 may be included in a circuit.

The storage unit can store files, such as drivers, libraries, and saved programs. The storage unit may store user data (eg, user preferences and user programs). In some cases, the computer system may include one or more additional data storage units external to the computer system, such as on a remote server that communicates with the computer system via an intranet or the Internet.

The computer system may communicate with one or more remote computer systems via a network. For example, a computer system can communicate with a remote computer system of a user (eg, an operator). Examples of remote computer systems include personal computers (eg, pocket PCs), tablet or tablet PCs (eg, Apple® iPad, Samsung® Galaxy Tab), telephones, smartphones (eg, Apple® iPhone, Android-enabled device, Blackberry®) or personal digital assistant. A user (eg, a client) can access the computer system via a network.

The methods as described herein may be implemented by means of machine (eg, computer processor) executable code stored on an electronic storage location of a computer system, such as in memory 4002 or an electronic storage unit 4004 on. Machine-executable or machine-readable code may be provided in the form of software. During use, processor 4006 can execute code. In some cases, the code may be retrieved from the storage unit and stored on memory ready for access by the processor. In some cases, the electronic storage unit may be eliminated, and the machine-executable instructions stored on memory.

The code may be precompiled and configured for use by a machine with a processor adapted to execute the code, or may be compiled during the execution phase. The code may be supplied in a programming language that may be selected to enable the code to be executed in a precompiled or as-compiled manner.

In some embodiments, the processor includes program code. The code may be program instructions. Program instructions may cause at least one processor (eg, a computer) to direct the feedforward and/or feedback control loop. In some embodiments, the program instructions cause the at least one processor to direct a closed loop and/or open loop control scheme. Control may be based at least in part on one or more sensor readings (eg, sensor data). One controller can direct multiple operations. At least two operations may be directed by different controllers. In some embodiments, different controllers may direct at least two of operations (a), (b), and (c). In some embodiments, different controllers may direct at least two of operations (a), (b), and (c). In some embodiments, the non-transitory computer-readable medium causes each distinct computer to direct at least two of operations (a), (b), and (c). In some embodiments, different non-transitory computer-readable media cause each different computer to direct at least two of operations (a), (b), and (c). A controller and/or computer-readable medium may direct any of the apparatuses disclosed herein or components thereof. A controller and/or computer-readable medium may direct any operation of the methods disclosed herein.

In some embodiments, at least one sensor is operatively coupled to a control system (eg, a computerized control system). Sensors may include light sensors, acoustic sensors, vibration sensors, chemical sensors, electrical sensors, magnetic sensors, mobility sensors, motion sensors, speed sensors, position sensors sensor, pressure sensor, force sensor, density sensor, distance sensor or proximity sensor. Sensors may include temperature sensors, weight sensors, material (eg, powder) content sensors, metric sensors, gas sensors, or humidity sensors. Metric sensors may include measurement sensors (eg, height, length, width, angle, and/or volume). Metrology sensors may include magnetic, acceleration, orientation, or optical sensors. Sensors can transmit and/or receive acoustic (eg, echo), magnetic, electronic, or electromagnetic signals. Electromagnetic signals may include visible light, infrared, ultraviolet, ultrasonic, radio waves, or microwave signals. The gas sensor can sense any of the gases described herein. The distance sensor may be a type of metric sensor. Distance sensors may include optical sensors or capacitive sensors. Temperature sensors may include bolometers, bimetals, calorimeters, exhaust thermometers, flame detection, Gardon meters, Golay cells, heat flux sensors, infrared thermometers, micro- bolometers, microwave radiometers, net radiometers, quartz thermometers, resistance temperature detectors, resistance thermometers, silicon bandgap temperature sensors, special sensors microwave/imagers, thermometers, thermistors, thermocouples, thermometers (eg, resistance thermometers) or pyrometers (eg, pyranometers, such as silicon pyranometers). The temperature sensor may include an optical sensor. The temperature sensor may include image processing. The temperature sensor may include a camera (eg, IR camera, CCD camera). Pressure sensors can include barometers, barometers, booster gauges, Bourdon gauges, hot filament ionization gauges, ionization gauges, McLeod gauges, U-shaped oscillating tubes , permanent downhole manometer, manometer, Pirani gauge, pressure sensor, manometer, tactile sensor or time pressure gauge. Position sensors may include growth meters, capacitive displacement sensors, capacitive sensing, free fall sensors, gravimeters, gyroscope sensors, impact sensors, inclinometers, integrated circuit piezoelectric sensors, Laser Rangefinders, Laser Surface Velocimeters, LIDAR, Linear Encoders, Linear Variable Differential Transformers (LVDTs), Liquid Capacitive Inclinometers, Odometers, Optical Sensors, Piezoelectric Accelerometers, Velocity Sensors , rotary encoders, rotary variable differential transformers, synchronizers, shock detectors, shock data recorders, tilt sensors, tachometers, ultrasonic thickness gauges, variable reluctance sensors or speed receivers. Optical sensors may include charge-coupled devices, colorimeters, contact image sensors, electro-optical sensors, infrared sensors, dynamic inductance detectors, light emitting diodes (eg, light sensors), Optically addressable potentiometric sensors, Nichols radiometers, fiber optic sensors, optical position sensors, photodetectors, photodiodes, photomultipliers, phototransistors, photoinductors detectors, photoionization detectors, photomultipliers, photoresistors, photoswitches, photocells, scintillation counters, Shack-Hartmann wavefront sensors (Shack-Hartmann), single-photon burst diodes, super Conductive nanowire single-photon detectors, transition edge sensors, visible light photon counters or wavefront sensors. One or more sensors can be connected to the control system (eg, to a processor, to a computer).

While preferred embodiments of the invention have been shown and described herein, it will be apparent to those skilled in the art that these embodiments are provided by way of example only. It is not intended that the present invention be limited to the specific examples provided within this specification. While the invention has been described with reference to the foregoing specification, the description and illustration of the embodiments herein are not intended to be construed in a limiting sense. Numerous changes, changes, and substitutions will occur to those skilled in the art without departing from this invention. Furthermore, it is to be understood that all aspects of the invention are not limited to the specific depictions, configurations or relative proportions set forth herein, which depend upon various conditions and variables. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. Accordingly, it is intended that the present invention shall cover any such alternatives, modifications, variations or equivalents. It is intended that the following patent claims define the scope of the invention and that methods and structures within the scope of these claims and their equivalents be covered thereby.

100: Electrochromic sheet 105: Glass flakes 110: Diffusion Barrier 115: first transparent conductive oxide layer (TCO) 120: Isolation trench 125: Electrochromic Stacking 130: Second TCO 135: Part 140: Area 145: Part 150: Laser scribed grooves 155: Laser scribed grooves 160: Laser scribed grooves 165: Laser scribed grooves 170: Parts 175: Part 200:IGU 201: Piece 205: Spacer 210: Second piece 215: Main sealing material 220: Secondary Seal 225: Interior Space 230: Enhanced pane 235: Resin 300: Electrochromic Device 302: Substrate 304: First Conductive Layer (CL) 306: Electrochromic Layer (EC) / Electrochromic Layer 308: Ion Conductive Layer (IC) 310: Counter Electrode Layer (CE) / Counter Electrode 314: Second Conductive Layer (CL) 316: Voltage source 320: Electrochromic Stacking 400: Electrochromic Device 402: Substrate 404: Conductive layer (CL) 406: Tungsten oxide electrochromic layer (EC) 408: Ion Conductive Layer (IC) 410: nickel tungsten oxide opposite electrode layer (CE) / nickel tungsten oxide opposite electrode 414: Conductive layer (CL) 416: Power/Voltage Source 420: Electrochromic Stacking 450: Window Controller 455: Microprocessor 460: Pulse Width Modulator 465: input 475: Configuration file 480: Internet 500: Enclosed body/room 505: Electrochromic Windows 510: External light sensor 601: Buildings 602: Window Control System / Hierarchical Control System 603: Main Controller 605: BMS 607a: Floor Controller/Network Controller 607b: Floor Controller/Network Controller 608: Local (e.g. terminal or leaflet) controller 610: Cloud Network 700: System 701: Internet 702: Window Control System 703: Main Controller 705: Network Controller 710: Terminal or louver controller 780: EC Device 790: Wall Switch 800: System Architecture 801: Cloud Network 810: Cloud-based 3D model system 820: Cloud-based clear sky module 840: Window Control System 872: Division 1 874: nth partition 890: Graphical User Interface (GUI) 892: Location Operations 894: Customer Success Manager (CSM) 898:Customer configuration entry 1410: Operation 1420: Operation 1430: Operation 1510: Operation 1520: Operation 1530: Operation 1540: Operation 1550: Operation 1560: Operation 1570: Operation 1580: Operation 2202: Operation 2210: Operation 2212: Operation 2214: Operation 2216: Operation 2220:Operation 2222: Operation 2224:Operation 2226:Operation 2230:Operation 2240:Operation 2600: Window Control System 2610: Operation 2620: Operation 2630: Operation 2640:Operation 2650:Operation 2660:Operation 2700: Window Control System 2701: Module A 2710: Module B 2710a: LSTM (univariate) submodule 2710b: DNN (multivariate) module 2711: Module C 2712: Module D 2713: Unsupervised classifier submodule/module E 2714: Process submodules after mapping to hue values 2716: Binary probability submodule 2719: Center of Gravity Averaging Module 2720: Window Controllers/Control Systems 2786: Voting submodule/voting logic 2800: Window Control System 2801: Module A 2810: Operation 2811: Module C1 2812: Module D1 2819: Center of Gravity Averaging Module 2820: Window Controller 2830: DNN module 2901: Action/Start event 2903: retrain operation 2905:Operation 2907: Operation 2909: Decision Operations 2911: Operation 2913: Operation 2915: Decision Operations 2917: End state 3001: Architecture 3003: Real-time model selection logic 3005: Kit 3007: Local sensor data 3009: Remote data 3011: Signature 3102: Line 3103: Line 3105: Line 3107: Line 3111: Line 3117: Line 3119: Line 3131: Line 3200: System 3201: Flowchart 3203: Operation 3205: Operation 3207: Operation 3209: Operation 3210: Location Management Console 3211: Operation/Virtual Sky Sensor Application 3212: Virtual Sky Sensor 3213: Operation 3215: Operation 3217: Operation 3220: Source 3250: Main Controller 3252: Data Extractor Application 3254: Field Library 3256: Control Logic 3258: Deep Neural Networks (DNN) 3262: First Network Controller 3264: Second network controller 3310: Location Management Console 3314: Virtual Sky Sensor 3320: Part 1 3330: Part II 3332: "MFST Remote" Sensor 3334: "Foresight Sensor" sensor 3400: System 3410: Location Management Console 3412: Virtual Sky Sensor Application / Virtual Sky Sensor 3420: Source 3450: Main Controller 3452: Data Extractor Application/Data Extractor 3454: Field Library 3456: Control Logic 3462: First Network Controller 3464: Second Network Controller 3500: System 3510: Location Management Console 3512: Virtual Sky Sensor Application / Virtual Sky Sensor 3520: Source 3550: Main Controller 3552: Data Extractor Application/Data Extractor 3554: Field Library 3556: Control Logic 3558: Deep Neural Networks (DNN) 3562: First Network Controller 3564: Second Network Controller 3700: Flowchart 3701: Block 3702: Block 3703:Block 3704:Block 3705:Block 3706:Block 3707:Block 3800: Flowchart 3801: Block 3802: Block 3803: Block 3804:Block 3805:Block 3806: Block 3807: output 3808: output 3900: Control System Architecture 3904: Local controller 3906: Floor Controller 3908: Main Controller 3910: External source 3920:Database 3924: Building Management Systems (BMS) 4000: Computer System 4001: Computer Network ("Network") 4002: Memory or memory parts 4003: Communication interface 4004: Electronic Storage Unit 4005: Peripherals 4006: Processing unit

The novel features of the invention are set forth in detail in the appended claims. A better understanding of the features and advantages of the present invention will be obtained by reference to the following embodiments and the accompanying drawings or figures (herein "drawings" and "drawings"), which illustrate illustrative utilization of the principles of the invention Examples, in the drawings:

1A - 1C show schematic diagrams of electrochromic devices (eg, electrochromic sheets) formed on a glass substrate;

2A and 2B show schematic cross-sectional views of an electrochromic sheet as described with respect to FIGS. 1A - 1C integrated into an insulating glass unit;

3A depicts a schematic cross-section of an electrochromic device;

3B depicts a schematic cross-section of an electrochromic device in a decolorized state (or transitioning to a decolorized state);

3C depicts a schematic cross-section of the electrochromic device shown in FIG. 3B but in a colored state (or transitioning to a colored state);

4 depicts a simplified block diagram of the components of the window controller;

5 is a schematic diagram of a room including a tintable window and at least one sensor in accordance with disclosed embodiments;

6 is a schematic diagram of a building, a control system, and a building management system (BMS) according to certain embodiments;

7 is a block diagram of components of a hierarchical control system and controlled devices;

8 is a general system architecture depicting the systems and users involved in maintaining a clear sky model over a cloud network and controlling tintable windows of a building based at least in part on data derived from output from the model , according to various implementations schematic diagram;

9 is an illustration of a 3D model of a building site according to one example;

10 is an illustration of a visual effect based at least in part on a 3D model and showing a glare/shadow and reflection model for direct sunlight rays from the sun at a location in the sky under clear sky conditions, according to one example;

11 is an illustrative example of data flow communicated between some of the systems of the system architecture shown in FIG. 8 ;

12 illustrates an example of logical operations of a clear sky module in generating clear sky model scheduling information, according to an embodiment;

Figure 13 is a schematic depiction of the model data flow of the cloud-based system through the system architecture shown in Figure 8 ;

14 is a flowchart of the general operations involved in initializing a 3D model on a 3D model platform, according to various embodiments;

15 is a flowchart of general operations involved in assigning attributes to 3D models, generating conditional models, and other operations involved in generating clear sky schedule information, according to various implementations;

16 is an example of visual effects of window management on a 3D modeling platform according to various embodiments;

17A is an example of a visual effect of partition management on a 3D modeling platform according to various implementations;

17B is an example of a visual effect of partition management on a 3D modeling platform according to various implementations;

18 is an example of an interface that may be used by a user in partition management, according to various implementations;

19 is an example of an interface that may be used by a user in partition management to review properties assigned to each partition , according to various implementations;

20A is an illustrative example of a two-dimensional user part drawn on a floor of a 3D model, according to an embodiment;

FIG. 20B is an illustrative example of a three-dimensional footprint created by three-dimensionalizing the two-dimensional object in FIG. 20A to the upper eye level;

21 is an illustrative example using a glare/shadow model that returns a glare-free condition based at least in part on the three-dimensional footprint shown in FIG. 20B ;

22 is an illustrative example using a direct reflection (one bounce) model that returns glare conditions based at least in part on the three-dimensional footprint shown in FIG. 20B ;

23 is a flowchart of actions and procedures for implementing user input to customize a clear sky 3D model of a building site, according to one aspect;

24 depicts a window control system with general control logic to control one or more partitions of tintable windows in a building , according to various embodiments;

25 depicts a flow diagram of control logic for making hue decisions based at least in part on outputs from modules A-E, according to various implementations;

26 depicts a flow diagram of control logic for making hue decisions based at least in part on output from a module, according to various implementations;

27A presents a flowchart illustrating one method of dynamic model selection;

27B presents example characteristic radiance curves for different clusters or models that can be used in real-time model selection;

28 presents a block diagram of an example of an architecture for dynamic model selection;

Figure 29 presents the results of a stress test run from noon to sunset for the dynamic model selection procedure;

30 presents a flow diagram of a procedure for model update using periodic input feature filtering;

Figure 31 represents an example of a model reinitialization and retraining architecture;

32 is an illustrative example of a predicted usage scenario implementation of a virtual sky sensor according to an aspect;

33 is an example of a location management console 3310 according to an aspect;

34 illustrates a quality assurance (Q/A) or test scenario implementation of a virtual sky sensor according to one aspect;

35 illustrates an A/B testing implementation of a virtual sky sensor according to an aspect;

36 illustrates sensor readings detected by a physical ring sensor, predicted/predicted sensor values determined by DNN, and use of predicted/predicted sense determined by DNN by control logic, according to one aspect A graph of the hue level determined by the detector value;

37 illustrates a flow diagram of operations in a learning system (eg, Foresight health monitor);

Figure 38 illustrates a flow chart of the quantization module;

Figure 39 illustrates a hierarchical control system and controlled devices; and

Figure 40 illustrates the processing system and its various components.

The figures and components therein may not be drawn to scale. Various components of the figures described herein may not be drawn to scale.

601: Buildings

602: Window Control System / Hierarchical Control System

603: Main Controller

605: BMS

607a: Floor Controller/Network Controller

607b: Floor Controller/Network Controller

608: Local (e.g. terminal or leaflet) controller

610: Cloud Network

Claims (217)

An apparatus for controlling at least one setting of one or more devices at a location, comprising one or more controllers having circuitry configured to: (a) operatively coupled to a sensor database configured to store sensor data communicated from a virtual sensor and from one or more data sources, the virtual sensor The sensors are configured to predict future sensor data; and (b) using sensor data retrieved from the sensor database to control or instruct to control the settings of a plurality of devices at a location. 2. The apparatus of claim 1, wherein the setting includes a hue level, wherein the one or more controllers are configured to: use the sensor data retrieved from the sensor database to determine or direct determination of a complex number tint levels of the tintable windows; and converting or directing the tint levels of the plurality of tintable windows to be converted to the determined tint levels. The apparatus of claim 1, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The apparatus of claim 1, wherein the future sensor data is based at least in part on a machine learning module. The apparatus of claim 1, wherein the sensor database is configured to store sensor data communicated from the virtual sensor. The apparatus of claim 5, wherein the sensor data communicated from the virtual sensor includes test data. The apparatus of claim 1, further comprising a deep neural network (DNN). The apparatus of claim 7, wherein the sensor data communicated from the virtual sensor to the sensor database is predicted by the deep neural network (DNN). The apparatus of claim 1, wherein the sensor database is configured to store sensor data communicated from the virtual sensor and from the one or more data sources. The apparatus of claim 1, wherein the one or more controllers comprise a hierarchical control system configured to transform one or more tintable windows. A non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more A plurality of processors perform the operations of one or more of the controllers as claimed in any one of items 1 to 10. The non-transitory computer readable program product of claim 11, wherein the one or more processors are operatively coupled to the sensor database, the sensor database configured to be stored from a virtual sensor sensors and/or sensor data communicated from one or more data sources. The non-transitory computer readable program product of claim 11, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 11, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 11, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 11, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A method for controlling at least one setting of one or more devices at a location that performs the operations of one or more controllers of any one of claims 1 to 10. A non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more A plurality of processors perform one or more operations comprising: controlling or directing control settings of a plurality of devices disposed at a location based at least in part on sensor data retrieved from a sensor database , wherein the one or more processors are operatively coupled to the sensor database configured to store senses communicated from a virtual sensor and from one or more data sources sensor data, the virtual sensor is configured to predict future sensor data. The non-transitory computer readable program product of claim 18, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The non-transitory computer readable program product of claim 18, wherein the future sensor data is based at least in part on a machine learning module. A method of controlling at least one setting of one or more devices at a location, the method comprising: controlling or directing based at least in part on sensor data retrieved from a sensor database and from a virtual sensor Controlling settings for a plurality of devices disposed at a location, the virtual sensor is configured to predict future sensor data. The method of claim 21, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The method of claim 21, wherein the future sensor data is based at least in part on a machine learning module. An apparatus for controlling the tint of at least one tintable window, comprising one or more controllers, the one or more controllers comprising circuitry, the one or more controllers configured to: (a) operatively coupled to a sensor database configured to (I) store senses conveyed from a virtual sensor configured to predict future sensor data; sensor data and (II) stored sensor data communicated from at least one physical sensor; (b) using the sensor data communicated from the virtual sensor to determine or guide the determination of a first set of hue states for at least one tintable window at a location, the first set of hue states comprising one or more first hue state; (c) using the sensor data communicated from the at least one physical sensor to determine or guide the determination of a second set of hue states for at least a tintable window at the location, the second set of hue states comprising one or more a second hue state; and (d) altering or directing altering the at least A tint of tintable windows. The apparatus of claim 24, wherein the sensor data communicated from the virtual sensor includes test data. The apparatus of claim 25, wherein the test data includes a time and/or date stamp and sensor values. The apparatus of claim 24, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The apparatus of claim 24, wherein the future sensor data is based at least in part on a machine learning module. The apparatus of claim 24, wherein the one or more controllers include one or more forecast modules configured to use sensor data to determine or direct determination of one or more outputs, the one or more outputs Including (i) a forecast of an environmental condition at a future time and/or (ii) a hue level of at least one tintable window at the future time. The apparatus of claim 29, wherein the one or more prediction modules comprise a neural network. The apparatus of claim 30, wherein the neural network comprises a deep neural network (DNN). The apparatus of claim 29, wherein the at least one sensor comprises a light sensor and/or an infrared sensor. The apparatus of claim 29, wherein the environmental condition comprises a weather condition. The apparatus of claim 29, wherein the one or more outputs comprise a roll value of a maximum first reading and/or a roll value of a minimum second sensor reading, wherein the roll value of the maximum first reading comprises a maximum light an average, median, or average value of sensor readings, and wherein the rolling value of the smallest second sensor reading includes one average, median, or average value of the smallest infrared readings. The apparatus of claim 29, wherein the one or more outputs comprise a rolling value of a maximum light sensor reading and/or a rolling value of a minimum infrared sensor reading, wherein the rolling value of the maximum light sensor reading includes one of the mean, median, or average of the maximum light sensor readings, and wherein the rolling value of the minimum infrared sensor readings includes one of the mean, median, or average of the minimum infrared readings. The apparatus of claim 29, wherein the one or more forecast modules are configured to calculate a centroid average from a time series of readings. The apparatus of claim 24, wherein (b) and (c) are performed by the same controller of the at least one controller. The apparatus of claim 24, wherein (b) and (c) are performed by different ones of the at least one controller. A non-transitory computer-readable program product for controlling the hue of at least one tintable window, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute a Operation of one or more of the controllers of any of items 24 to 36 is requested. The non-transitory computer readable program product of claim 39, wherein the one or more processors are operatively coupled to a sensor database configured to (i) store from Sensor data communicated by a virtual sensor and/or (ii) sensor data communicated from at least one physical sensor stored. The non-transitory computer readable program product of claim 39, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 39, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 39, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 39, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A method of controlling the tint of at least one tintable window that performs the operations of one or more controllers as claimed in any one or more of items 24 to 36. A non-transitory computer-readable program product for controlling the hue of at least one tintable window, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute a program comprising: Operation of the following: (a) using sensor data communicated from a virtual sensor configured to predict future perceptions to determine or guide the determination of a first set of hue states for at least one tintable window at a location; instrument data, the first hue state set includes one or more first hue states; (b) using the sensor data communicated from the at least one physical sensor to determine or guide the determination of a second set of hue states for at least a tintable window at the location, the second set of hue states comprising one or more The second hue state; and (c) altering the at least one colorable based at least in part on (i) the first set of hue states, (ii) the second set of hue states, or (iii) the first set of hue states and the second set of hue states window tint. The non-transitory computer readable program product of claim 46, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The non-transitory computer readable program product of claim 46, wherein the future sensor data is based at least in part on a machine learning module. A method of controlling the tint of at least one tintable window, the method comprising: (a) using sensor data communicated from a virtual sensor configured to predict future perceptions to determine or guide the determination of a first set of hue states for at least one tintable window at a location; instrument data, the first hue state set includes one or more first hue states; (b) using the sensor data communicated from the at least one physical sensor to determine or guide the determination of a second set of hue states for at least a tintable window at the location, the second set of hue states comprising one or more The second hue state; and (c) altering the at least one colorable based at least in part on (i) the first set of hue states, (ii) the second set of hue states, or (iii) the first set of hue states and the second set of hue states window tint. The method of claim 49, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The method of claim 49, wherein the future sensor data is based at least in part on a machine learning module. An apparatus for controlling the state of at least one device, the apparatus comprising one or more controllers comprising circuitry, the one or more controllers configured to: (a) operatively coupled to a sensor database configured to store sensor data communicated from a virtual sky sensor and communicated from at least one physical sensor the sensor data, wherein the sensor data communicated from the virtual sky sensor includes test data; (b) use the test data to determine or guide the determination of a first set of control states for at least one device; (c) using the sensor data communicated from the at least one physical sensor to determine or guide the determination of a second set of control states for the at least one device; and (d) altering or directing altering the at least one based at least in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control The status of the device. The apparatus of claim 52, wherein the one or more controllers are configured to: (I) compare the first set of control states with the second set of control states; and (II) based at least in part on the comparison, using Or direct the use of one of the first set of control states and the second set of control states to control the at least one device. The apparatus of claim 52, wherein the virtual sensor is configured to predict future sensor data. The method of claim 54, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The method of claim 54, wherein the future sensor data is based at least in part on a machine learning module. The apparatus of claim 52, wherein the at least one device includes at least one tintable window, wherein the first set of control states includes a first set of hue states, and wherein the second set of control states includes a second set of hue states. The apparatus of claim 52, wherein (b) and (c) are performed by the same controller of the at least one controller. The apparatus of claim 52, wherein (b) and (c) are performed by different ones of the at least one controller. A non-transitory computer-readable program product for controlling the state of at least one device, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute items as claimed Operation of one or more of the controllers of any of 52 to 57. The non-transitory computer readable program product of claim 60, wherein the one or more processors are operatively coupled to a sensor database configured to (i) store from A virtual sensor communicates sensor data and (ii) stores sensor data communicated from at least one physical sensor. The non-transitory computer readable program product of claim 60, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 60, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 60, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 60, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A method of controlling the state of at least one device that performs the operations of one or more controllers as claimed in any one of items 52 to 57. A non-transitory computer-readable program product for controlling the state of at least one device, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute the following: Operator's operation: (a) use the test data included in the sensor data communicated from the virtual sky sensor to determine or guide the determination of a first set of control states of the at least one device; (b) using sensor data communicated from at least one physical sensor to determine or direct determination of a second set of control states for the at least one device; and (c) altering or directing altering the at least one based at least in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control the state of the device, wherein the one or more processors are operatively coupled to a sensor database configured to (I) store sensor data communicated from the virtual sky sensor and (II) ) stores sensor data communicated from the at least one physical sensor. The non-transitory computer readable program product of claim 67, wherein the virtual sensor is configured to predict future sensor data. The non-transitory computer readable program product of claim 68, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The non-transitory computer readable program product of claim 68, wherein the future sensor data is based at least in part on a machine learning module. A method of controlling the state of at least one device, the method comprising: (a) use the test data included in the sensor data communicated from the virtual sky sensor to determine or guide the determination of a first set of control states of the at least one device; (b) using sensor data communicated from at least one physical sensor to determine or direct determination of a second set of control states for the at least one device; and (c) altering or directing altering the at least one based at least in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control The status of the device. The method of claim 71, wherein (I) the sensor data communicated from the virtual sky sensor and (II) the sensor data communicated from the at least one physical sensor are stored in a sensor in the database. The method of claim 71, wherein the virtual sensor is configured to predict future sensor data. The method of claim 73, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The method of claim 73, wherein the future sensor data is based at least in part on a machine learning module. An apparatus for controlling the state of at least one device, the apparatus comprising one or more controllers comprising circuitry, the one or more controllers configured to: (a) operability ground coupled to a sensor database configured to (i) store sensor data communicated from a virtual sensor, and (ii) store from at least one physical sensor communicated sensor data, wherein the sensor data communicated from the virtual sensor includes test data for a first test case and a second test case; (b) use the test data for the first test case to determine or guide the determination of a first set of control states for at least one device; (c) use the test data for the second test case to determine or guide the determination of a second set of control states for the at least one device; and (d) altering or directing altering the at least one based at least in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control The status of the device. The apparatus of claim 76, wherein the one or more controllers are configured to: compare (i) the first set of control states with (ii) the second set of control states; and based at least in part on the comparison, using Or direct the use of one of the first set of control states and the second set of control states to control the at least one device. The apparatus of claim 76, wherein the virtual sensor is configured to predict future sensor data. The apparatus of claim 78, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The apparatus of claim 78, wherein the future sensor data is based at least in part on a machine learning module. The apparatus of claim 76, wherein the at least one device includes at least one tintable window, wherein the first set of control states includes a first set of hue states, and wherein the second set of control states includes a second set of hue states. The apparatus of claim 76, wherein (b) and (c) are performed by the same controller of the at least one controller. The apparatus of claim 76, wherein (b) and (c) are performed by different ones of the at least one controller. A non-transitory computer-readable program product for controlling the state of at least one device, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute items as claimed Operation of one or more controllers of any of 76 to 81. The non-transitory computer readable program product of claim 84, wherein the one or more processors are operatively coupled to a sensor database configured to (i) store from sensor data communicated by a virtual sensor; and (ii) stored sensor data communicated from at least one physical sensor, wherein the sensor data communicated from the virtual sensor includes data for a first Test data of a test case and a second test case. The non-transitory computer readable program product of claim 84, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 84, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 84, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 84, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A method of controlling the state of at least one device that performs the operations of one or more controllers as in any one of claims 76-81. A non-transitory computer-readable program product for controlling the state of at least one device, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute the following: Operator's operation: (b) use the test data for the first test case to determine or guide the determination of a first set of control states for at least one device; (c) use the test data for the second test case to determine or guide the determination of a second set of control states for the at least one device; and (d) altering or directing altering the at least one based at least in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control the state of the device, wherein the one or more processors are operatively coupled to a sensor database configured to (i) store sensor data communicated from a virtual sensor; and ( ii) storing sensor data communicated from at least one physical sensor, wherein the sensor data communicated from the virtual sensor includes test data for a first test case and a second test case. The non-transitory computer readable program product of claim 91, wherein the virtual sensor is configured to predict future sensor data. The non-transitory computer readable program product of claim 92, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The non-transitory computer readable program product of claim 92, wherein the future sensor data is based at least in part on a machine learning module. A method of controlling the state of at least one device, the method comprising: (b) use the test data for the first test case to determine or guide the determination of a first set of control states for at least one device; (c) use the test data for the second test case to determine or guide the determination of a second set of control states for the at least one device; and (d) altering or directing altering the at least one based at least in part on (i) the first set of control states, (ii) the second set of control states, or (iii) the first set of control states and the second hue state control The status of the device. The method of claim 95, wherein a sensor database is configured to: (i) store sensor data communicated from a virtual sensor; and (ii) store data communicated from at least one physical sensor Sensor data. The method of claim 95, wherein the sensor data communicated from the virtual sensor includes test data for a first test case and a second test case. The method of claim 95, wherein the virtual sensor is configured to predict future sensor data. The method of claim 98, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The method of claim 98, wherein the future sensor data is based at least in part on a machine learning module. An apparatus for controlling the state of at least one device, the apparatus comprising one or more controllers comprising circuitry, the one or more controllers: (a) configured to be operatively coupled to a sensor database configured to store test data communicated from a virtual sensor; and (b) include one or more forecast modules configured to use the test data communicated from the virtual sensor to determine or facilitate the determination that (I) includes a future time One or more outputs of a first predicted environmental condition and/or (ii) a first hue level of at least one tintable window at the future time. The apparatus of claim 101, wherein the virtual sensor is configured to predict future sensor data. The apparatus of claim 102, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The apparatus of claim 102, wherein the future sensor data is based at least in part on a machine learning module. The apparatus of claim 101, wherein the one or more forecast modules are configured to use sensor data from readings obtained by at least one physical sensor to determine one or more additional outputs. The apparatus of claim 105, wherein the future time is a first future time, and wherein the one or more additional outputs include a second predicted environmental condition at a second future time and/or the at least one colorable The window is at a second hue level at the second future time. The apparatus of claim 106, wherein the first future time and the second future time are different future times. The apparatus of claim 106, wherein the first future time and the second future time are the same future time. The apparatus of claim 101, wherein the virtual sensor is a virtual sky sensor configured to predict a facility at a future time at a facility in which the at least one tintable window is disposed External sensor data. The apparatus of claim 101, wherein the one or more prediction modules comprise a neural network. The apparatus of claim 110, wherein the neural network comprises a deep neural network (DNN). The apparatus of claim 101, wherein the one or more forecasting modules include logic to determine the output using machine learning. The apparatus of claim 101, wherein the at least one sensor comprises a light sensor and/or an infrared sensor. The apparatus of claim 105, wherein the first predicted environmental condition and/or the second environmental condition comprises a weather condition. The apparatus of claim 101, wherein the one or more outputs comprise a roll value of a maximum first reading and/or a roll value of a minimum second sensor reading, wherein the roll value of the maximum first reading comprises a maximum light an average, median, or average value of sensor readings, and wherein the rolling value of the smallest second sensor reading includes one average, median, or average value of the smallest infrared readings. The apparatus of claim 101, wherein the one or more outputs comprise a rolling value of a maximum light sensor reading and/or a rolling value of a minimum infrared sensor reading, wherein the rolling value of the maximum light sensor reading includes one of the mean, median, or average of the maximum light sensor readings, and wherein the rolling value of the minimum infrared sensor readings includes one of the mean, median, or average of the minimum infrared readings. The apparatus of claim 101, wherein the one or more forecast modules are configured to calculate a centroid average from a time series of readings. The apparatus of claim 101, wherein the one or more controllers are configured to control an environment in which an enclosure of the at least one tintable window is disposed. A non-transitory computer-readable program product for controlling the state of at least one device, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute items as claimed Operation of one or more of the controllers of any one of 101 to 118. The non-transitory computer readable program product of claim 119, wherein the one or more processors are operatively coupled to a sensor database configured to be stored from a virtual sensor Test data transmitted by the tester. The non-transitory computer readable program product of claim 119, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 119, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 119, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 119, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A method of controlling the state of at least one device that performs the operations of one or more controllers as claimed in any one of items 101 to 118. A non-transitory computer-readable program product for controlling the state of at least one device, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processors to execute one or more an operation, the one or more processors configured to be operatively coupled to a sensor database configured to store test data communicated from a virtual sensor; and The non-transitory computer readable program product includes one or more forecast modules configured to use the test data communicated from the virtual sensor to determine or facilitate a determination (I) comprising One or more outputs of a first predicted environmental condition at a future time and/or (II) at least one tintable window at a first hue level at the future time. The non-transitory computer readable program product of claim 126, wherein the virtual sensor is configured to predict future sensor data. The non-transitory computer readable program product of claim 127, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The non-transitory computer readable program product of claim 127, wherein the future sensor data is based at least in part on a machine learning module. A method of determining the hue state of one or more tintable windows, the method comprising: (a) generating training data for a plurality of external conditions by labeling sensor data from radiation profiles with external conditions from weather feed data; (b) using the training data generated for the plurality of external conditions to train at least one machine learning model for the plurality of external conditions, wherein the at least one machine learning model is trained to determine that the one or more shadeable windows are in the the hue states under a plurality of external conditions, or the information used to determine the hue states; and (c) altering the hue of the one or more tintable windows at least in part by using the determined hue states. The method of claim 130, wherein the virtual sensor is configured to predict future sensor data. The method of claim 131, wherein the future sensor data is based at least in part on readings from one or more physical sensors. The method of claim 130, wherein the plurality of external conditions are weather conditions. The method of claim 130, wherein the weather feed data is received from a third party. The method of claim 130, wherein the radiation profiles are segmented according to the plurality of external conditions of different types received from the weather feed. The method of claim 135, wherein the sensor data in each segment is tagged with one of the plurality of external conditions. The method of claim 130, wherein the plurality of external conditions include a sunny condition, a partially cloudy condition, a foggy condition, a rainy condition, a hail condition, a stormy condition, and/or a smog condition. A non-transitory computer-readable program product for determining the hue state of one or more tintable windows, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processing The processor performs operations as the method of any one of request items 130-137. The non-transitory computer readable program product of claim 138, wherein the one or more processors are operatively coupled to the one or more shadeable windows. The non-transitory computer readable program product of claim 138, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 138, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 138, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 138, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. An apparatus for determining a tint state of one or more tintable windows, at least one controller including circuitry and configured to perform operations as the method of any one of claims 130-137. The apparatus of claim 144, wherein at least two of the operations are performed by the same controller of the at least one controller. The apparatus of claim 144, wherein at least two of the operations are performed by different ones of the at least one controller. A non-transitory computer-readable program product for determining the hue state of one or more tintable windows, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more processing The device performs operations that include: (a) generating or instructing the generation of training data for a plurality of external conditions by labeling sensor data from radiation profiles with external conditions from weather feed data; (b) using or instructing to use the training data generated for the plurality of external conditions to train at least one machine learning model for the plurality of external conditions, wherein the at least one machine learning model is trained to determine the one or more colorable the hue states of the window under the plurality of external conditions, or information used to determine the hue states; and (c) altering or directing altering the hue of the one or more tintable windows at least in part by using the determined hue states. The non-transitory computer readable program product of claim 147, wherein the virtual sensor is configured to predict future sensor data. The non-transitory computer readable program product of claim 148, wherein the future sensor data is based at least in part on readings from one or more physical sensors. An apparatus for determining a hue state of one or more tintable windows, the apparatus comprising at least one controller having circuitry, the at least one controller configured to: (a) operatively coupled to the one or more tintable windows; (b) generating or instructing the generation of training data for a plurality of external conditions by labeling sensor data from radiation profiles with external conditions from weather feed data; (c) using or instructing to utilize the training data generated for the plurality of external conditions to train at least one machine learning model for the plurality of external conditions, wherein the at least one machine learning model is trained to determine the one or more colorable the hue states of the window under the plurality of external conditions, or information used to determine the hue states; and (d) altering or directing altering the hue of the one or more tintable windows at least in part by using the determined hue states. The apparatus of claim 150, wherein the virtual sensor is configured to predict future sensor data. The apparatus of claim 151, wherein the future sensor data is based at least in part on readings from one or more physical sensors. An apparatus for controlling at least one setting of one or more devices at a location, comprising one or more controllers having circuitry configured to: (a) operatively coupled to a virtual sensor that predicts predicted sensor data of a physical sensor at a second time at a first time; (b) operatively coupled to a physical sensor that measures real sensor data at the second time; (c) comparing or instructing to compare the predicted sensor data with the real sensor data to produce a result; (d) altering or directing altering one or more operations of the virtual sensor to produce an altered virtual sensor based at least in part on the result; and (e) controlling or directing control of the at least one setting of the one or more devices based at least in part on the altered virtual sensor. The apparatus of claim 153, wherein the one or more controllers are configured to use or direct the use of the results to monitor a comparison within a time window between: (i) after the second time continuous predicted sensor data that is continuously predicted; and (ii) continuous real sensor data that is continuously acquired after the second time to produce continuous results. The apparatus of claim 154, wherein the modification of the one or more operations of the virtual sensor is based at least in part on the length of the time window. The apparatus of claim 153, wherein the predicted sensor data is based at least in part on a machine learning module. The apparatus of claim 153, wherein the one or more controllers are configured to send or direct the sending of a notification based at least in part on the result. The apparatus of claim 153, wherein at least one controller is configured to utilize or direct the utilization of data from the virtual sensor and the physical sensor for controlling the operation of the one or more devices at the location the at least one setting. The apparatus of claim 153, wherein the one or more controllers utilize a network. The apparatus of claim 153, wherein the one or more devices comprise a tintable window. The apparatus of claim 153, wherein the one or more devices comprise a building management system. The apparatus of claim 153, wherein the one or more controllers are configured to control an environment of the site. The apparatus of claim 153, wherein the virtual sensor utilizes machine learning to predict the sensor data. The apparatus of claim 153, wherein at least two of (a) to (e) are performed by the same one of the at least one controllers. The apparatus of claim 153, wherein at least two of (a) to (e) are performed by different ones of the at least one controllers. A non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more A plurality of processors perform operations of one or more of the controllers as claimed in any one of items 153-163. The non-transitory computer readable program product of claim 166, wherein the one or more processors are operatively coupled to a virtual sensor that predicts a physical sensor at a first time Predicted sensor data at a second time. The non-transitory computer readable program product of claim 166, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 166, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 166, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 166, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A non-transitory computer-readable program product for controlling at least one setting of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the one or more Multiple processors perform operations including: (a) comparing or instructing to compare predicted sensor data with real sensor data to generate a result, wherein the predicted sensor data was generated by a virtual sensor at a first time, wherein the predicted sensor data is data of a physical sensor at a second time after the first time, and wherein the real sensor data is measured by the physical sensor at the second time; and (b) altering or directing altering one or more operations of a virtual sensor to produce an altered virtual sensor based at least in part on the result; and (c) controlling or directing control of the at least one setting of the one or more devices based at least in part on the altered virtual sensor, wherein the one or more processors are operatively coupled to the virtual sensor and the physical sensor. The non-transitory computer readable program product of claim 172, wherein the predicted sensor data is based at least in part on a machine learning module. A method of controlling at least one setting of one or more devices at a location, comprising: (a) predicting the predicted sensor data at a first time by using a virtual sensor; (b) using a physical sensor to measure real sensor data at a second time; (c) comparing the predicted sensor data with the real sensor data to generate a result; (d) altering one or more operations of the virtual sensor based at least in part on the result to produce an altered virtual sensor; and (e) controlling the at least one setting of the one or more devices based at least in part on the altered virtual sensor. The method of claim 174, wherein the predicted sensor data is based at least in part on a machine learning module. A non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the One or more processors perform operations such as the method of claim 174 . The non-transitory computer readable program product of claim 173, wherein the one or more processors are operatively coupled to the physical sensor. The non-transitory computer readable program product of claim 173, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 173, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 173, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 173, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A method of determining the gain of sunlight and/or glare protection in a facility, the method comprising: (a) using the measured sensor data of one or more physical sensors to generate, according to a first logic, a first instruction that transforms a hue of at least one tintable window disposed in the in the facility; (b) using virtual sensor data of one or more virtual sensors, the virtual sensor data including the predicted future sense, to generate a second instruction using a second logic to shift the hue of a tintable window instrument information; and (c) comparing the first order with the second order to determine any gain in daylight and/or glare protection in the facility. The method of claim 182, wherein the predicted future sensor data is based at least in part on data from one or more physical sensors. The method of claim 182, wherein the predicted future sensor data is based at least in part on a machine learning module. The method of claim 182, wherein the first instruction carries a first timestamp, and wherein the second instruction carries a second timestamp, and wherein comparing the first instruction to the second instruction includes comparing the first instruction The first time stamp and the second time stamp. The method of claim 182, wherein the one or more physical sensors comprise a light sensor and/or an infrared sensor. The method of claim 182, further comprising distinguishing between tinting the at least one tintable window to a darker hue and tinting the at least one tintable window to a lighter hue. The method of claim 182, further comprising applying one or more filtering operations to the measured sensor data and/or the virtual sensor data. The method of claim 188, wherein the one or more filtering operations comprise square wave filtering. A non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the One or more processors perform operations such as the method of claim 182 . The non-transitory computer readable program product of claim 190, wherein the one or more processors are operatively coupled to one or more physical sensors. The non-transitory computer readable program product of claim 190, wherein at least two of the operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 190, wherein at least two of the operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 190, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 190, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. An apparatus for determining the gain of sunlight and/or glare protection in a facility, the apparatus comprising at least one controller comprising circuitry, the at least one controller configured to: (a) operatively coupled to at least one physical sensor, at least one tintable window, and at least one virtual sensor; (b) receive or direct the receipt of measured sensor data from at least one physical sensor; (c) using or directing the use of the measured sensor data to generate, according to a first logic, a first instruction to transform a hue of at least one tintable window disposed in the facility; (d) receiving or directing receipt of virtual sensor data for at least one virtual sensor including predicted future sensor data; (e) using or directing the use of the virtual sensor data to generate, using a second logic, a second instruction that shifts the hue of a tintable window; and (f) comparing or directing the comparison of the first instruction with the second instruction to determine any gain in daylight and/or glare protection in the facility. The apparatus of claim 196, wherein the first instruction carries a first timestamp, and wherein the second instruction carries a second timestamp, and wherein the at least one controller is configured at least in part by Comparing the first timestamp with the second timestamp compares or directs comparing the first instruction with the second instruction. The apparatus of claim 196, wherein the predicted future sensor data is based at least in part on data from the at least one physical sensor. The apparatus of claim 196, wherein the predicted future sensor data is based at least in part on a machine learning module. The apparatus of claim 196, wherein the one or more physical sensors comprise a light sensor and/or an infrared sensor. The apparatus of claim 196, wherein the at least one controller is configured to differentiate or direct a distinction between tinting the at least one tintable window to a darker hue and tinting the at least one tintable window to a lighter hue. The apparatus of claim 196, wherein the at least one controller is configured to apply or direct application of one or more filtering operations to the measured sensor data and/or the virtual sensing device information. The apparatus of claim 202, wherein the one or more filtering operations comprise square wave filtering. The apparatus of claim 196, wherein at least two of (a) to (f) are performed by the same controller of the at least one controller. The apparatus of claim 196, wherein at least two of (a) to (f) are performed by different ones of the at least one controller. A non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the The processor or processors perform one or more operations of the at least one controller as claimed in any of items 196-203. The non-transitory computer readable program product of claim 206, wherein the one or more processors are operatively coupled to one or more physical sensors. The non-transitory computer readable program product of claim 206, wherein at least two of the one or more operations are performed by the same one of the one or more processors. The non-transitory computer readable program product of claim 206, wherein at least two of the one or more operations are performed by different ones of the one or more processors. The non-transitory computer-readable program product of claim 206, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. The non-transitory computer-readable program product of claim 206, wherein the non-transitory computer-readable program product comprises a non-transitory computer-readable medium. A non-transitory computer-readable program product for controlling at least one level of one or more devices at a location, the non-transitory computer-readable program product, when read by one or more processors, causes the or more processors perform one or more operations including: (a) receive or direct the receipt of measured sensor data from at least one physical sensor; (b) using or directing the use of the measured sensor data to generate, according to a first logic, a first instruction to transform a hue of at least one tintable window disposed in the facility; (c) receiving or directing receipt of virtual sensor data for at least one virtual sensor including predicted future sensor data; (d) using or directing the use of the virtual sensor data to generate, using a second logic, a second instruction that shifts the hue of a tintable window; and (e) comparing or directing the comparison of the first order with the second order to determine any gain in daylight and/or glare protection in the facility, wherein the one or more processors are operatively coupled to at least one physical sensor, at least one shadeable window, and at least one virtual sensor. The non-transitory computer readable program product of claim 212, wherein the predicted future sensor data is based at least in part on data from the at least one physical sensor. The non-transitory computer readable program product of claim 212, wherein the predicted future sensor data is based at least in part on a machine learning module. A method of controlling at least one level of one or more devices at a location, the method comprising: (a) receive or direct the receipt of measured sensor data from at least one physical sensor; (b) using or directing the use of the measured sensor data to generate, according to a first logic, a first instruction to transform a hue of at least one tintable window disposed in the facility; (c) receiving or directing receipt of virtual sensor data for at least one virtual sensor including predicted future sensor data; (d) using or directing the use of the virtual sensor data to generate, using a second logic, a second instruction that shifts the hue of a tintable window; and (e) comparing or directing the comparison of the first instruction and the second instruction to determine any gain in daylight and/or glare protection in the facility. The method of claim 215, wherein the predicted future sensor data is based at least in part on data from the at least one physical sensor. The method of claim 215, wherein the predicted future sensor data is based at least in part on a machine learning module.

Images