Application for controlling optically switchable device

Abstract

Software applications are used to control the optical state of one or more optically switchable windows or other optical products installed in a building structure, such as a building. The applications allow a user to send and / or receive data and / or commands for controlling the switchable optical products. In some embodiments, these applications provide an interface with a window network controller that directly or indirectly controls windows in a building structure. Related processes involving the application may include user authentication, debugging, adaptive control, and decisions as to whether to allow an action or change requested by the user. In some embodiments, the application allows a user to directly control the shading state of one or more shadable windows. In some embodiments, the application allows a user to change rules or attributes associated with controlling the switchable optical product.

Description

[0001] Incorporated by Reference

[0002] The Application Data Sheet is filed concurrently with this specification as a part of this application. Each application to which this application claims the benefit or priority of which is identified in the Application Data Sheet filed concurrently is incorporated herein by reference in its entirety and for all purposes.

[0003] Copyright Notice

[0004] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright holder has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. Technical Field

[0005] The present application relates to a software application for controlling an optically switchable device, in particular an optically switchable window. Background Art

[0006] Switchable optical devices such as electrochromic devices reversibly cycle between two or more optical states, such as a transparent state and a colored state. Switching between these states is controlled by applying a predefined current and / or voltage to the device. The device controller typically includes a low voltage power supply and can be configured to work with radiation and other environmental sensors, although these are not required. The controller can also be configured to interface with an energy management system, such as a computer system that controls the switchable optical device based on factors such as season, time of day, security conditions, and measured environmental conditions. Such an energy management system can significantly reduce a building's energy consumption, reduce glare, and maximize daytime lighting.

[0007] Although electrochromic devices and related optically switchable devices were invented several decades ago, they have not yet begun to realize their full commercial potential. Part of the difficulty is the lack of versatility in the modes of operation of electrochromic devices. Additionally, known control systems for electrochromic devices have limited functionality and fail to take into account some of the unique characteristics of electrochromic devices as well as user preferences. Summary of the invention

[0008] Disclosed herein is a software application for controlling the optical state of one or more optically switchable windows or other optical products installed in a building structure such as a building. The application is designed to allow a user to send and / or receive data and / or commands for controlling these switchable optical products. In some embodiments, these applications provide an interface with a window network controller, which directly or indirectly controls the windows in the building structure. In such an embodiment, the network controller acts as a receiver and transmitter for data and commands for controlling switchable optical products. The network controller can process certain data and commands used by the application. The processing may involve user authentication, debugging, adaptive control, and a decision on whether to allow the action or change requested by the user. In some embodiments, the application allows the user to directly control the optical state of one or more optically switchable windows. In some embodiments, the application allows the user to change the rules or attributes associated with controlling the switchable optical product.

[0009] According to some embodiments, a method for controlling one or more optically switchable windows includes, in response to a first user input, controlling, using at least one control system: (a) a daily schedule for changing the transmittance of at least one of the optically switchable windows based on time of day, and (b) execution of a corresponding change in the transmittance at a first time of day, the first time of day corresponding to a first wake-up time selected by the user.

[0010] In some examples, the corresponding change in transmittance may include changing the shade state of the electrochromic window from dark to transparent.

[0011] In some examples, the user input may be performed through a graphical user interface of a remote device communicatively coupled to the at least one control system. In some examples, the remote device may be wirelessly coupled to the at least one control system.

[0012] In some examples, the first time of day may be close to and no later than a user-selected wake-up time.

[0013] In some examples, the user input may include a selection of one or more areas within a residence having associated windows, and a corresponding transmittance change may be performed only for those associated windows.

[0014] In some examples, each window may include an electrochromic device, and changing the transmittance may include changing a light blocking state of the electrochromic device.

[0015] In some examples, the method may also include: in response to a second user input, using the at least one control system to control: (c) a weekly schedule for changing the transmittance of at least one of the optically switchable windows based on the time of day and the day of the week, and (d) execution of corresponding changes in the transmittance according to the weekly schedule, the weekly schedule including at least one day having a user-selected second wake-up time different from the first wake-up time.

[0016] In some examples, the window may exhibit a characteristic transition time for transitioning between light blocking states, and execution of a corresponding change in transmittance begins prior to the first wake-up time by an amount of time substantially equal to the characteristic transition time.

[0017] In some examples, the control system may be configured to normally follow a baseline control program, and the method may further include overriding the baseline control program to the extent necessary to follow a daily schedule. In some examples, overriding the baseline control program may include the execution of a corresponding change in transmittance, regardless of whether following the baseline control program causes the transmittance of the one or more optically switchable windows to have a different transmittance during the daily schedule. In some examples, the different transmittance may be a second shading state at a first time of the day, and the at least one control system may be configured to avoid changing the transmittance of the one or more optically switchable windows to the second shading state at the first time of the day. In some examples, the baseline control program may be based at least in part on sensor data and clear weather data, and the daily schedule may maintain and change the transmittance of the one or more optically switchable windows in a manner different from the baseline control program.

[0018] According to some specific embodiments, a control system includes: at least one interface that is communicatively coupled to one or more optically switchable windows; a remote device interface that is configured to receive communications from a remote device, wherein the communications include a first user input; and logic circuitry that is used to control, in response to the first user input: (a) a daily schedule for changing the transmittance of at least one of the optically switchable windows based on time of day, and (b) execution of a corresponding change in the transmittance at a first time of day, the first time of day corresponding to a first wake-up time selected by the user.

[0019] In some examples, the corresponding change in transmittance may include changing the shade state of the electrochromic window from dark to transparent.

[0020] In some examples, the user input may be performed through a graphical user interface of a remote device communicatively coupled to the at least one control system. In some examples, the remote device may be wirelessly coupled to the at least one control system.

[0021] In some examples, the first time of day may be close to and no later than a user-selected wake-up time.

[0022] In some examples, the user input may include selection of one or more areas within a residence having associated windows, and performance of corresponding changes in transmittance is performed only for those associated windows.

[0023] In some examples, each window may include an electrochromic device, and changing the transmittance may include changing a light blocking state of the electrochromic device.

[0024] In some examples, the control system may be further configured to control, in response to a second user input: (c) a weekly schedule for changing the transmittance of at least one of the optically switchable windows based on the time of day and the day of the week, and (d) execution of corresponding changes in the transmittance according to the weekly schedule, the weekly schedule including at least one day having a user-selected second wake-up time that is different from the first wake-up time.

[0025] In some examples, the window may exhibit a characteristic transition time for transitioning between light blocking states, and execution of a corresponding change in transmittance may begin prior to the first wake-up time by an amount of time substantially equal to the characteristic transition time.

[0026] In some examples, the control system may be configured to normally follow a baseline control program, and further configured to override the baseline control program to the extent necessary to follow a daily schedule. In some examples, the override of the baseline control program may include the execution of a corresponding change in transmittance, regardless of whether following the baseline control program causes the transmittance of the one or more optically switchable windows to have a different transmittance during the daily schedule. In some examples, the different transmittance may be a second shading state at a first time of the day, and the control system is configured to avoid changing the transmittance of the one or more optically switchable windows to the second shading state at the first time of the day. In some examples, the baseline control program may be based at least in part on sensor data and clear weather data, and the daily schedule maintains and changes the transmittance of the one or more optically switchable windows in a manner different from the baseline control program.

[0027] According to some specific implementations, a non-transitory computer-readable medium includes instructions for causing at least one control system to perform a method, the method comprising: in response to a first user input, using the at least one control system to control: (a) a daily schedule for changing the transmittance of at least one of the optically switchable windows based on time of day, and (b) execution of a corresponding change in the transmittance at a first time of day, the first time of day corresponding to a first wake-up time selected by the user.

[0028] In some examples, the corresponding change in transmittance may include changing the shade state of the electrochromic window from dark to transparent.

[0029] In some examples, the user input may be performed through a graphical user interface of a remote device communicatively coupled to the at least one control system. In some examples, the remote device may be wirelessly coupled to the at least one control system.

[0030] In some examples, the first time of day may be close to and no later than a user-selected wake-up time.

[0031] In some examples, the user input may include selection of one or more areas within a residence having associated windows, and performance of corresponding changes in transmittance is performed only for those associated windows.

[0032] In some examples, each window may include an electrochromic device, and changing the transmittance includes changing a light blocking state of the electrochromic device.

[0033] In some examples, the method may also include: in response to a second user input, using the at least one control system to control: (c) a weekly schedule for changing the transmittance of at least one of the optically switchable windows based on the time of day and the day of the week, and (d) execution of corresponding changes in the transmittance according to the weekly schedule, the weekly schedule including at least one day having a user-selected second wake-up time different from the first wake-up time.

[0034] In some examples, the window may exhibit a characteristic transition time for transitioning between light blocking states, and execution of a corresponding change in transmittance may begin prior to the first wake-up time by an amount of time substantially equal to the characteristic transition time.

[0035] In some examples, the control system may be configured to normally follow a baseline control program, and the method may further include overriding the baseline control program to the extent necessary to follow a daily schedule. In some examples, overriding the baseline control program may include the execution of a corresponding change in transmittance, regardless of whether following the baseline control program causes the transmittance of the one or more optically switchable windows to have a different transmittance during the daily schedule. In some examples, the different transmittance may be a second shading state at a first time of the day, and the at least one control system may be configured to avoid changing the transmittance of the one or more optically switchable windows to the second shading state at the first time of the day. In some examples, the baseline control program may be based at least in part on sensor data and clear weather data, and the daily schedule may maintain and change the transmittance of the one or more optically switchable windows in a manner different from the baseline control program.

[0036] According to some specific implementations, a method for controlling one or more optically switchable windows includes: receiving a first user input of a wake-up time of a day; maintaining the one or more optically switchable windows in a dark shading state for a period of time before the wake-up time; and transitioning the one or more optically switchable windows from the dark shading state to a transparent shading state, so that the one or more optically switchable windows are substantially in the transparent shading state at the wake-up time of a day.

[0037] In some examples, the method may further include receiving a second user input for a bedtime, and causing the one or more optically switchable windows to transition to a dark shade state, such that the one or more optically switchable windows are substantially in the dark shade state at the bedtime, wherein the time period substantially spans between the bedtime and the wake-up time. In some examples, the method may further include preventing the one or more optically switchable windows from transitioning to another shade state during the time period according to one or more other control programs.

[0038] According to some specific implementations, a control system for controlling one or more optically switchable windows is configured to: receive a first user input of a wake-up time of the day; maintain the one or more optically switchable windows in a dark shading state for a period of time before the wake-up time; and transition the one or more optically switchable windows from the dark shading state to a transparent shading state, so that the one or more optically switchable windows are substantially in the transparent shading state at the wake-up time of the day.

[0039] In some examples, the control system may be further configured to: receive a second user input for a bedtime; and cause the one or more optically switchable windows to transition to a dark shade state, such that the one or more optically switchable windows are substantially in the dark shade state at the bedtime, wherein the time period substantially spans between the bedtime and the wake-up time. In some examples, the control system may be further configured to prevent the one or more optically switchable windows from transitioning to another shade state during the time period according to one or more other control programs.

[0040] According to some specific implementations, a non-transitory computer-readable medium includes instructions for causing at least one control system to execute a method, the method comprising: receiving a first user input of a wake-up time of a day; maintaining one or more optically switchable windows in a dark shading state for a period of time before the wake-up time; and causing the one or more optically switchable windows to transition from the dark shading state to a transparent shading state, so that the one or more optically switchable windows are substantially in the transparent shading state at the wake-up time of a day.

[0041] In some examples, the method may further include: receiving a second user input for a bedtime; and causing the one or more optically switchable windows to transition to a dark shade state, such that the one or more optically switchable windows are substantially in the dark shade state at the bedtime, wherein the time period substantially spans the bedtime and the wake-up time. In some examples, the method may further include preventing the one or more optically switchable windows from transitioning to another shade state during the time period according to one or more other control programs.

[0042] These and other features and advantages of the disclosed embodiments will be presented in more detail below with reference to the associated drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1A is a schematic diagram of a system for a remote device that presents a user interface for an application for controlling an optically switchable device on a network.

[0044] Figures 1B to 1F A schematic diagram of the network, remote devices, and applications that perform various device control functions.

[0045] Figure 1G is a schematic diagram of an alternative logical or hardware architecture for networks, remote devices, and applications.

[0046] Figure 2 is a flow chart depicting a series of operations that may be implemented using a window control application that provides an interface on a remote device.

[0047] Figure 3is a flow chart depicting a debugging process that may be implemented using a window control application that provides an interface on a remote device.

[0048] FIG. 4A to FIG. 4G are screen shots depicting the main screen and configuration screens for the window control application as displayed on a computing tablet.

[0049] FIG. 5A to FIG. 5H is a screenshot of the main screen for the window control application displayed on a smartphone.

[0050] FIG. 6A to FIG. 6E is a screenshot of an application user interface used to group devices on a network, such as during debugging.

[0051] FIG. 7A to FIG. 7M is a screenshot depicting a user interface for entering or editing schedule-based rules for a window control application.

[0052] Fig. 8A and Figure 8B is a screenshot depicting a user interface for entering or editing sensor-based rules for a window control application.

[0053] Fig. 9 is a flow chart depicting an adaptive control algorithm implemented with the aid of a window control application.

[0054] Fig.10 A method for controlling a window according to some embodiments is shown. DETAILED DESCRIPTION

[0055] introduce

[0056] The following disclosure relates to the use of software applications to control and / or monitor one or more switchable optical products in an architectural structure, such as a building. Although the present disclosure emphasizes certain types of applications running on certain types of computing devices (e.g., wireless, handheld devices), it should be understood that other types of applications and computing devices may also be employed. Similarly, although the present disclosure emphasizes certain types of optically switchable devices in certain types of architectural structures, the present disclosure is not limited thereto.

[0057] In various embodiments discussed herein, the software application will be described as controlling one or more devices, such as optically switchable products, particularly optically switchable windows. However, the embodiments disclosed herein are not limited to switchable windows. Examples of other types of optically switchable products include mirrors, displays, etc. In the context of the present disclosure, these products are generally provided in a non-pixelated form.

[0058] An optically switchable product includes a switchable optical device, such as an electrochromic device, disposed on a surface, in a substrate, or between substrates. The substrate allows the optical device to provide an observable optical response. In certain embodiments, the substrate is solid and transparent, such as a transparent glass or plastic sheet. The glass substrate can be processed in a manner suitable for a particular end use. For example, the glass substrate can be strengthened or unstrengthened. Examples of strengthened glass substrates are those that are tempered or laminated. Examples of suitable substrate types and methods for manufacturing optical devices using such substrates are described in U.S. Patent Application No. 12 / 941,882, filed on November 8, 2010, entitled "ELECTROCHROMIC WINDOW FABRICATION METHODS," which is incorporated herein by reference in its entirety.

[0059] It should be understood that although the disclosed embodiments focus on devices and methods for controlling electrochromic (EC) windows, the concepts disclosed herein can be applied to other types of optically switchable devices. Examples of other optically switchable devices include liquid crystal devices and suspended particle devices. Optically switchable devices can absorb, reflect and / or scatter light. Such devices have controllable light absorption, color, reflectivity and / or scattering properties. These properties can vary with spectral position; that is, they can vary with the wavelength of the incident radiation.

[0060] In various embodiments, an optically switchable device is a thinner device that changes an optical state in response to an electrical input. The device reversibly cycles between two or more optical states. The switching between these states is controlled by applying a predefined current and / or voltage to the device. The device typically includes two thin conductive sheets across at least one optically active layer. The electrical input that drives the optical state change is applied to the thin conductive sheet. In certain embodiments, the input is provided by a bus bar that is electrically connected to the conductive sheet.

[0061] Electrochromic devices are described in various references, including U.S. Patent Application No. 12 / 645,111 filed on December 22, 2009, U.S. Patent Application No. 12 / 645,159 filed on December 22, 2009, U.S. Patent Application No. 12 / 772,055 filed on April 30, 2010, U.S. Patent Application No. 12 / 772,075 filed on April 30, 2010, U.S. Patent Application No. 12 / 814,277 filed on June 11, 2010, U.S. Patent Application No. 12 / 814,279 filed on June 11, 2010, and U.S. Patent Application No. 15 / 762,077 filed on March 21, 2018, each of which is incorporated herein by reference in its entirety.

[0062] Architectural structures that may house optically switchable products controlled by the applications disclosed herein include rooms, buildings (including multi-room buildings), vehicles, large displays (including collections of displays), etc. Whenever reference is made to a building, architectural structure, or the like, it is intended that the reference includes residential buildings, commercial buildings, greenhouses, etc., and extends to vehicles, displays, etc. In various embodiments, the architectural structure includes one or more controllers for controlling the switching of optically switchable products contained in the architectural structure.

[0063] Application software, sometimes referred to as "applications" or "apps", is computer software designed to help users perform specific tasks (such as controlling the shading state in switchable windows). Many applications provide interfaces for remotely controlling one or more devices such as optically switchable products. Applications can be bundled with computers and their system software, or can be released separately. Application software contrasts with system software and middleware, which manage and integrate the functions of computers, but usually do not directly apply them to perform tasks that are beneficial to users. System software serves applications, and applications in turn serve users. Application software applies the capabilities of a specific computing platform or system software (e.g., a network server such as a window controller) to specific purposes. Some applications are available for versions of several different platforms, such as Apple iOS, MacOS, Android, Linux, etc. In various embodiments, applications are provided to users through a graphical user interface presented on a device, which is separate from one or more switchable optical products, and these products are directly or indirectly controlled by the application.

[0064] The applications described herein monitor and / or control one or more "devices". An optically switchable product is one type of device. Examples of other types of devices include controllers for controlling optically switchable products, sensors for supporting control decisions for switchable products, lighting controllers, etc.

[0065] In some embodiments, the application is presented to the user on a "remote device" that can communicate with the controller of the switchable optical product. The remote device can communicate with the controller via a wireless or wired connection. Many of the examples given herein depict remote devices that use wireless communication. In all cases, a wired link can be used instead.

[0066] For example, the remote device can be a portable device or a non-portable device, such as a desktop computer or a terminal. In some specific implementations, the remote device is a smart phone, a tablet computer, a personal digital assistant (PDA), or any other wireless device. The remote device can communicate directly with the controller, or, as described below, communicate indirectly with the controller via a network controller.

[0067] The remote device provides an interactive user interface for allowing a user to control or monitor one or more switchable optical products. In certain embodiments, the remote device displays a graphical representation of the switchable optical product being monitored or controlled as part of a graphical user interface or "GUI".

[0068] In certain embodiments, the remote device includes a CPU with a cache. The device also includes a communication interface, such as a wireless interface that allows the CPU to communicate with a network and / or controller in a building structure that includes one or more switchable optical products. In some specific implementations, the application is implemented with software running on the CPU. The code for application may reside on the remote device or be stored elsewhere. The user interface and associated applications are displayed on the display of the remote device. The remote device may also include other features, such as a large memory, a location indicator (e.g., a GPS device) and / or a digital camera. As indicated, the wireless device may be a mobile phone, a tablet computer, a PDA or a personal computer in various examples.

[0069] Figures 1A to 1F An example of a system is presented in which a mobile or remote device displays a user interface that allows a user to interface with a network of controllers, sensors, and switchable windows. In this specification, the terms "mobile device" and "remote device" are used interchangeably, although "remote device" is generic for both devices requiring a hardwired connection and mobile devices (i.e., wireless devices).

[0070] Figure 1A A network 101 is schematically depicted that interacts with a remote device 111 to give a user 119 control over the optical state of one or more switchable windows or other optical products under the control of the network 101. An application facilitates the interaction between the user 119 and the network 101. Instructions for executing the software application may be stored on the remote device 111, or the network window controller 103, or elsewhere. The application may run on (or be executed on) a variety of devices including the remote device 111, the network window controller 103, and the building management system 105, and / or run on (or be executed on) other hardware including shared hardware (such as hardware employed in the cloud).

[0071] The network 101 may be implemented in a building, a collection of buildings, a vehicle, or other building structure having one or more optically switchable windows. For convenience, it will be assumed that the network 101 is implemented in a building. However, as described above, it should be understood that the network may also be implemented on other types of building structures. In the depicted embodiment, the network has a hierarchy of window controllers, meaning that the building has many different windows that may experience a variety of environmental conditions and provide solar radiation to many different types of rooms or areas.

[0072] At the highest level in the depicted hierarchy, the network controller 103 provides full network control and instructions for the intermediate level window controllers 113a, 113b, and 113c. Of course, depending on the size and complexity of the building, additional window controllers may be provided in parallel with 113a to 113c. In some embodiments, the network controller implements an algorithm for controlling one or more optically switchable devices or other devices. Examples of such algorithms are given in U.S. Patent Application No. 13 / 772,969 [VIEWP049] filed on February 21, 2013, which is incorporated herein by reference in its entirety.

[0073] In the depicted embodiment, window controller 113a in turn controls three lower level window controllers 115a, 115b, and 115c. Figure 1A 1 and 117d. Although not shown, the intermediate window controllers 113b and 113c may themselves control one or more low-level window controllers. Alternatively, the intermediate-level window controllers 113b and 113c may each directly control one or more windows. In the depicted embodiment, the low-level window controller 115a directly controls windows 117a, 117b, 117c, and 117d. These four windows may be, for example, windows in a particular room of an office building, windows on one side of an office building, windows facing the same direction in a given room of a building, windows on one or more sides of a vehicle, or substantially any other collection of windows that may benefit from being directly controlled by a single window controller.

[0074] The network-level window controller 103 can interact with other control systems installed in the building. Examples of such other control systems include security systems, building management systems, and the like. Building management systems, illustrated by the building management system (BMS) 105 in the network 101, conventionally control a large number of functions in large commercial or residential buildings or building complexes. Typically, the building management system controls heating, ventilation, multimedia, and air conditioning in these buildings. In some cases, the building management system will include the functions of other systems such as security systems and window control systems. In the described embodiments, the network window controller 103 is a separate entity connected to the building management system 105. The interface allows the network window controller 103 to access many types of information that may be collected or determined for the building management system. Examples of such information include building sensor information (e.g., the current temperature in one or more rooms), the current energy consumption of one or more environmental devices that function under the control of the BMS, and the like. The interaction between the network window controller 103 and the building management system 105 also allows the building management system to instruct the network window controller to take specific actions that may be appropriate. In certain embodiments, the network window controller function is integrated into the BMS or other building control systems. Examples of master network controllers and building networks including a hierarchical arrangement of BMS and window controllers are given in U.S. Patent Application No. 13 / 049,756, filed March 16, 2011, which is incorporated herein by reference in its entirety. For a description of certain aspects of a suitable master window controller, see U.S. Patent Application No. 13 / 772,969 [VIEWP049], filed February 21, 2013, which was previously incorporated herein by reference. In one example, the window controller 103 is a suitably programmed controller, such as a controller from CAN2GO (now owned by Schneider Electric of Rueil-Malmaison, France).

[0075] Each controller used in the network of controller and switchable device can have many different logic or structural arrangements.Usually, the controller of switchable optical device is designed or configured (e.g., programmed) to realize the control algorithm of the above type.In various embodiments, the controller determines the current or voltage of the appropriate level to be applied, and continues to apply such voltage or current to the switchable device.The controller can also detect the current or voltage level to ensure that the optical device works correctly.In addition, the controller can have various additional features, such as timer, charge detector (e.g., coulomb meter), oscillator, etc. Various designs and components of the controller are given in U.S. patent application No. 3 / 049,756 filed on March 16, 2011 [Agent Docket No. SLDMP007], U.S. patent application No. 13 / 049,750 filed on March 16, 2011 [Agent Docket No. SLDMP008], U.S. patent application No. 13 / 449,248 filed on April 17, 2012 [SLDMP041], and U.S. patent application No. 13 / 449,251 filed on April 17, 2012 [SLDMP042], each of which is incorporated herein by reference in its entirety.

[0076] In some embodiments, the controller (e.g., controller 115a) is integrated with the optical device or housing. In a particular embodiment, the controller is integrated into the housing or into the seal of an insulating glass unit (IGU) containing the switchable optical device. Various arrangements of integrated controllers are given in U.S. Patent Application No. 13 / 049,750 [Attorney Docket No. SLDMP008] and U.S. Patent Application No. 13 / 326,168 [Attorney Docket No. SLDMP034], filed on December 14, 2011, with inventor Brown, entitled "CONNECTORS FOR SMART WINDOWS," which are incorporated herein by reference in their entirety.

[0077] The controller typically includes a microprocessor for making a switching decision based on available inputs, sending commands, and receiving commands. In some embodiments, the controller includes a power converter that is configured to convert a low voltage into the power requirement of the optically switchable device. This power can be fed to the switchable device via a driver circuit (power driver). In one embodiment, the controller has a redundant power driver so that in the event of a failure, there is a backup power supply and the controller does not need to be replaced or repaired.

[0078] The controller may also include one or more communication ports and associated communication circuitry for receiving and sending commands and / or data to other network entities such as a master controller. In one embodiment, the power cord is also used to send and receive communications, for example, via a protocol such as Ethernet.

[0079] In one embodiment, the power and communication functions of the optical device controller may be combined in a single chip, such as a programmable logic device (PLD) chip, a field programmable gate array (FPGA), etc. Such integrated circuits may combine logic functions, control functions, and power functions in a single programmable chip. In one embodiment, the logic circuit is configured to independently control each of two or more switchable optical devices.

[0080] The controller may have wireless capabilities for communication and / or power functions. Wireless communication transmission frequencies such as RF and / or IR may be used. Wireless protocols such as Bluetooth, WiFi, Zigbee, EnOcean, etc. may be used to send instructions to the microprocessor and cause the microprocessor to send data to, for example, other window controllers and / or a building management system.

[0081] In various embodiments, the remote device 111 communicates with the network window controller 103 via a wireless link. In other embodiments, the remote device communicates with the controller 103 via a wired link. In either case, the remote device may communicate directly or indirectly with the window controller 103. In some embodiments, the remote device communicates directly or indirectly with the building management system 105, which in turn communicates with the network window controller 103 during operation of the window control application. In such an embodiment, the building management system 105 itself may play a role in the application or in providing the information required by the application. In the depicted embodiment, the remote device 111 communicates with the full network window controller 103 via a wireless link through the Internet (cloud 109) and a router 107 that is part of the hardware of the network 101. Many other configurations for achieving communication between the remote device 111 and the network window controller 103 are possible and will be apparent to those skilled in the art.

[0082] In some embodiments, the window controller application acts on information collected by one or more sensors in the building. For example, the application can use the sensor output to decide whether to put a particular window into a blackout state. In addition, the information from the sensor can also be presented to the user 119 via the remote device 111. For example, the temperature at the window, solar radiation, etc. can be displayed on the device 111 via the application. In some embodiments, one or more sensors communicate wirelessly with one or more window controllers.

[0083] In certain embodiments, sensors are distributed throughout the building and are associated with various physical or structural features on the building. In alternative embodiments, only one or a few sensors are employed. For example, see certain embodiments disclosed in U.S. Patent Application No. 13 / 772,969 [VIEWP049] filed on February 21, 2013, which has been previously incorporated herein by reference. In the depicted embodiment, sensors 121d and 121e are associated with windows 117a and 117d, respectively. In the depicted embodiment, sensor 121c is provided with window controller 115a. In addition, sensor 121a is associated with network window controller 103, and sensor 121b is associated with building management system 105. Typically, although not necessarily, sensors are fixed to or positioned in close proximity to the network entities to which they are associated. Examples of sensors that may be associated with window controllers include light sensors, temperature sensors, and occupancy sensors.

[0084] As an example, the sensor may be a temperature sensor, a light sensor, an occupancy sensor, etc. Various types of sensors may be used to measure sunlight or artificial light, one example being a photometric sensor such as a silicon photodiode. Another type of sensor is a pyranometer, which measures solar irradiance in a larger spectrum of solar radiation. The temperature of the device or any location may be inferred by an algorithm or measured directly using a sensor such as a thermocouple, thermistor, or RTD (resistive thermal device).

[0085] These applications facilitate user interaction with a networked window controller, providing various functions associated with controlling the optical properties of one or more windows controlled by the networked window controller. Examples of these different activities are described in Figures 1B to 1F Given in.

[0086] Figure 1B A scenario is depicted where a user 119 interacts with a remote device 111 and chooses to directly cause windows 117a and 117d to enter a blackout state. The remote device presents application functionality that allows the user to manually adjust the optical properties of one or more windows. For example, if the windows are electrochromic windows, the user can manually set the blackout state of one or more windows that he or she selects using the application. As explained more fully below, the application may provide one or more user interface features that allow the user to select one or more windows and / or the blackout state of one or more windows. Figure 4A , Figure 4B , Figure 5A and Figure 5B An example of a user interface that allows such manual control is shown in .

[0087] In certain embodiments, the available shading state that the user can select is limited to a transparent state or a shading state. In other words, there are only two options available for the user. In the opposite extreme case, the window may have a continuously variable shading level that can be controlled. The application for controlling such windows can allow the user to select any desired shading level between the maximum and minimum shading available for the window. To this end, the application includes, for example, a user interface slider representing all available shading states. Between the extreme cases of a binary option for selecting shading and a continuously variable option for selecting shading, the window can provide one or more intermediate discrete shading states. In various embodiments, the total number of available shading states for manual control can be 3, 4, 5, 6, 7, 8, 9, 10 or more such discrete states. In a specific embodiment, the window includes two or more glass layers, such as the case of an insulating glass unit (IGU). Each glass layer may include its own electrochromic device, which is configured to provide 4 or more discrete shading states to the IGU. See U.S. Patent Application No. 12 / 851,514, filed August 5, 2010, which is incorporated herein by reference in its entirety.

[0088] Another example of the type of user control that can be provided by the window control application is the ability to define and / or modify rules or properties for automatically controlling window shading. As explained more fully below, examples of rules include schedule-based rules and sensor-based rules. In some embodiments, the application allows the user to define such rules by selecting various schedule parameters, environmental parameters, etc. FIG. 7 , Fig. 8A and Figure 8B An example of a user interface suitable for adding or editing such rules is presented in .

[0089] The "manual" functionality provided to the user by the window control application sometimes overrides existing shading rules or routines programmed or otherwise configured in the network window controller 103. In some embodiments, the user is only allowed to manually override for a limited time period, such as approximately 1 to 3 hours. This hard limit on the override can prevent energy-inefficient settings (or other potentially undesirable settings) from remaining in place long after the user responsible for the override has left the affected area. Limits on manual overrides can be programmed into, for example, the window control application and / or the network window controller.

[0090] Figure 1CA situation is schematically depicted in which a user 119 uses a remote device 111 to input a new rule based on a comparison result of an output value of a sensor 121d with a threshold value. When the user inputs the new rule through a user interface provided by an application displayed on the remote device 111, the rule is stored on the network window controller 103, where it is executed to affect control of a specific window in response to the output value from the sensor 121d. The rule stored on the controller 103 is depicted by reference numeral 123.

[0091] Another feature provided by some window control applications is to group various devices into groups that are processed according to certain rules or other logical structures under the control of the network controller. As described below, this grouping can be performed during a part of the commissioning process.

[0092] The devices that are usually grouped for the purpose of similar treatment are window controllers, sensors, windows, and optionally switches for controlling lights or windows. Any one, two or three of these elements may be included in a single group. There are many reasons why people want to group these devices for similar treatment. Usually, a group of devices are treated similarly due to being affected by similar environmental conditions, such as being exposed to sunlight at certain times of the day. Another reason for grouping devices is that various devices are shared by a specific group of workers or residents who need similar environmental conditions. Other reasons for grouping devices include ease of control using, for example, a single button, and reducing infrastructure costs by sharing sensors / switches across multiple controllers. Similar treatments applied to devices in user-defined groups include, for example, rules or attributes for controlling windows, and the identity of specific users who are given control of these devices (usually through window control applications), as well as the roles of these individuals who can exert influence on the grouped devices.

[0093] Figure 1D Schematically depicted is a scenario where a user 119 defines a group through a user interface provided on a remote device 111. The user selects sensors 1201c and 121d as well as window controller 115a and windows 117a to 117c as devices within a new group identified as "G1." In the specific example, these devices are all associated with the north-facing side of the building under the control of the network window controller 103.

[0094] Sometimes, a user may attempt to exert control over the network 101 by using a window control application and discover that the network window controller does not allow the user to perform the request. There may be various policy reasons why the user's ability to group, program, and / or manually control elements of the network 101 is limited. One example is that the action proposed by the user may be inconsistent with the policy of limiting the amount of energy consumed during peak load periods to no more than a certain threshold level. Another example may be that the user's input is inconsistent with the programming input from another user who has higher authority over the device affected by the user's request.

[0095] Figure 1E A situation is depicted in which a user 119 makes a request to control one or more features of the network 101 and the request is analyzed by the network window controller 103 and is found to be unacceptable. In the depicted embodiment, when the window controller 103 makes this determination, the application sends a notification back to the user 119 that his or her request has been denied. The notification may take the form of a message displayed on the remote device 111.

[0096] Another example of the type of interaction between a user and a network window controller is through a concept referred to herein as "adaptive control." With adaptive control, a window control application (or another application acting in conjunction with the window control application) is intelligent enough to recognize when a special change in the rules or procedures for controlling one or more windows needs to be made. When the controller makes this recognition, it can use the window control application to notify the user of the proposed adaptive change. The user can then choose to approve or reject the proposed adaptive change. Note that in an alternative embodiment, the user does not have this choice and the system will automatically make the change. This automatic change may be accompanied by notifying the user of the change made via the application. In the example of adaptive control, the application infers that the windows in a room should be placed in a shaded state between noon and 1 p.m. on weekdays based on the user's history of manually shaded windows during that time period. Figure 1F The network controller 103 is schematically depicted recognizing that an adaptive change is appropriate and notifying the user 119 via the remote device 111. In some embodiments, the window control application has a "demo" mode that allows the user to go through the GUI screens in a simulation without being connected to the system, such as Figures 1A to 1F This is useful for sales and / or training purposes. Many different types of installation mechanisms can be used to install the window control application on the remote device. In one example, the application can be downloaded from iTunes. TM or other publicly available app stores or other software to download to the user's device.

[0097] Figures 1A to 1F Many variations on the system depicted in can be used with the mobile application as described herein. One variation is Figure 1G The system 191 depicted in FIG. 191 uses a computer 193 to execute the Figure 1A One or more functions of the main network controller 103 of the system 191. Examples of such functions include remote access, user management, system diagnostics, database services, and scalability. Some or all of the functions of the network window controller 103 can be offloaded to a computer 193 in the system 191. Examples of these functions include one or more of rule logic, adaptive programming, debugging, device configuration, and device grouping. In the described embodiment, the computer 193 is connected to the router 107, the building management system 105, and the network window controller 103'. In certain embodiments, the computer 193 is a "socket computer". Socket computers are known to those skilled in the art. It is typically a compact but powerful computer server that can be implemented in the form of an AC power outlet or an AC adapter. In various embodiments, the socket computer is configured to provide a bridge to cloud-based services. Figure 1G The system depicted in can be used in conjunction with any method or functionality disclosed herein to create a network of windows controllable by a mobile application.

[0098] Flowchart of application features

[0099] In some embodiments, the window control application is used in the setup process of installed windows and other devices to be controlled using the application. Figure 2 An example of such a setup process and the subsequent deployment and usage phases is provided.

[0100] Figure 2 A flow chart illustrating handling of an uncommissioned device in an architectural structure such as a building is presented. See block 203. A process that may be accomplished or facilitated using a window control application includes (i) a step of commissioning a device (205), followed by a step of (ii) creating a user profile for an application user who may control the commissioned device (207), followed by a step of (iii) creating rules and responding to user requests by interacting with the application during normal operation after commissioning and creating the user profile (209).

[0101] debug

[0102] Debugging is a way to inventory, group and verify the devices available to the window control application. Debugging is usually triggered by the new installation of optically switchable products and / or associated controllers in the building structure. In some cases, the installation will be carried out while the building structure is being constructed. In other embodiments, the installation will occur at a later date, such as a retrofit application. In some embodiments, debugging can be implemented in stages, where each stage occurs after a new set of devices are installed in the building structure. For example, in the first stage, some electrochromic windows can be installed on the south side of an existing building. These windows and their associated controllers will be debugged soon after installation. Later, additional electrochromic windows and associated controllers are installed on the east and west sides of the building. These new, later installed windows are then debugged. After that, the windows on the north side of the building will be replaced with electrochromic windows and associated controllers. At this point, another stage of debugging is performed. Perhaps, after that, more sensors, controllers and / or other devices are installed in the building, and thereafter these devices are properly debugged. In some embodiments, under any event that triggers possible debugging, the application presents a notification through its user interface. The notification may be followed by receipt of a user instruction to initiate a debugging process.

[0103] Figure 3 A simple commissioning process is depicted in 205. The initial phase of commissioning involves taking an inventory (sometimes referred to as "discovering") of uncommissioned devices in the building structure. This is done in Figure 3 303 of . In a typical embodiment, the inventory of devices involves executing an application's discovery routine for discovering networked devices that have not yet been debugged. The program for discovering undebugged devices may be run on a network server, a remote device, a cloud, or some combination of these devices. Such a program may broadcast a discovery request over the network, and the undebugged devices are programmed to respond to the discovery request with certain information about themselves. For example, the devices may respond with their class and identification. The identification should uniquely identify each device within a given class. Examples of classes include a window or insulating glass unit class, a window controller class, a network controller class, a temperature sensor class, a light sensor class, an occupancy sensor class, a manual override switch class, and the like.

[0104] In another embodiment, the discovery routine receives a list of devices that are ready to be debugged. The list may be provided in the form of a table, a spreadsheet, a database view, etc. Upon receiving such a list, the routine updates an internal list of available devices under its control.

[0105] Examples of debugging methods include the following:

[0106] Method 1 (on-site group creation):

[0107] (a) All devices are connected and powered on; each device identifies itself by device type / id etc. and is then added to a list for that particular device type and visible on the user interface.

[0108] (b) The user then creates a group via the user interface and adds members by selecting them from the list created in (a) using a drawing / graph and / or document containing the grouping information. If desired, the user using the user interface can confirm that the member actually exists in the domain of the group by sending a signal and observing a response.

[0109] Method 2 (off-site group creation):

[0110] (a) Import a list of all devices from a design document or file, along with groups and possibly other information.

[0111] (b) After power-up, the presence of all components is confirmed (eg similar to method 1), and any missing or additional components are marked on the application's user interface and subsequently added or deleted by the user.

[0112] (c) If necessary, the user can confirm that the member actually exists in the group's domain by sending a signal and observing the response.

[0113] Each of these categories will have specific properties associated with it. For example, a class for a photosensor might specify that the photosensor provides output in specific light level increments (in foot candles). The class may also specify other properties of the device, such as its dynamic range, its manufacturer, its model type, etc. The class may include additional information, such as a URL or contact for maintenance and replacement details provided by the supplier, etc. Further information about the categories is given in the example API for the window control application below.

[0114] The inventory process may also discover the location of each device within the building. This may involve, for example, uploading installation data specifying the location of each device from a recent installation. As an example, such information may be provided in a spreadsheet, table, or other textual arrangement. As with the categories and IDs, the location information may be stored on the window network, in the cloud, on a remote device, or any combination of these elements. Such configuration information may be created or modified remotely from where the device is located. At the appropriate time, the configuration information is downloaded or otherwise transmitted to the window network controller and / or window application of the affected building. This allows configuration to be performed by an entity (such as a supplier of optically switchable windows) that does not have access to the network of the building where the window is installed.

[0115] Next, in Figure 3In process 205, the inventoried devices are grouped as indicated in block 305. Grouping may be facilitated using a user interface in a remote user application, an application running on a network server, or the like. Using a graphical user interface of a window control application, a user may add a new group, modify an existing group, delete a group, merge two or more groups, create a hierarchy of groups, and the like. The user interface makes all inventoried devices available for grouping via a display or other mechanism. Using the interface, the user identifies one or more devices to include in a defined group. Fig. 6A and Figure 6B A sample user interface screenshot for facilitating grouping is provided in . See also Figure 1D and related discussions.

[0116] Device groups may be created for a variety of reasons. Typically, the devices in a group have one or more attributes in common. In some embodiments, the common attribute is the common location of the devices in the group. In some embodiments, the common attribute is controlled by a user or group of users who have access to the group of devices.

[0117] In many cases, grouping reduces implementation costs. For example, all floors on the same side of a building may be able to utilize a single light sensor across one or more groups. Additionally, grouping can reduce the burden (and reduce complexity) on any upstream BMS system or manual override switch, since such entities only need to send commands to the group, rather than all or some of the devices in the group.

[0118] Furthermore, the grouping can be done in a hierarchical manner. In other words, a group can belong to a higher-level group; that is, a lower-level group can be a subset of a higher-level group. As an example, a group may be limited to optically switchable windows on the north-facing side of a building. This "north-facing side" group is contained within a higher-level group, which includes optically switchable windows from all sides of the building, but does not include windows from any other buildings. "Buildings" are in turn contained within an even higher-level group, which includes multiple building groups, each of which can be part of a building complex, for example. The benefit of this design is that users of the mobile application are able to quickly identify device problems, and only after identifying that a problem exists, do they need to expend effort to determine the exact location of the problem. For example, a window network administrator for an entire building complex is able to view the device status of an entire super device group within the complex.

[0119] A packet is a logical abstraction of a physical network in a window management strategy. It can be n-layer hierarchical, with command and control information propagating from top to bottom, and status and state information propagating from bottom to top.

[0120] It should be understood that grouping and modifying groups can be performed outside the context of debugging. Therefore, although one or more groups can be established during debugging, such one or more groups can be modified, deleted, etc. long after debugging has been completed.

[0121] Finally, the commissioning process 205 ends with a test and verification phase 307. In this process, all the devices counted and grouped are tested to ensure that they are functioning properly and that they are the devices displayed during the inventory process. In one embodiment, testing and verification is accomplished via a handheld remote device that receives user input, and the user moves through the building, checking the functionality of the devices from one device to another, which are individually identified in the user application. As part of the testing process, the application can test individual windows or other devices to determine whether they respond to manual commands issued through the application. The application can also test to determine whether a specific sensor is operating as expected. For example, a temperature sensor can be exposed to a heat source, and its output as presented in the application is used to determine that the sensor correctly shows an elevated temperature. If any device is found to be faulty or misrepresented during the testing and verification phase, these devices can be appropriately fixed, replaced, and / or re-identified.

[0122] User roles in the application

[0123] In various implementations, the window control application defines and applies roles specific to the user of the application. This can be Figure 2 100 . A single role may allow a user with such a role to have a certain range of control. In some embodiments, the role defines the windows or other devices that a user can control via the window control application. The devices that can be controlled by a user of a given role can have certain common attributes. For example, they can be in a specific geographic location (e.g., a building or a portion of a building, such as a group of north-facing windows and sensors in a building, room, or compound), they can be a defined class or type (e.g., they are all light sensors, such as light sensors provided by a specific supplier), or they can be a defined group of devices specified during commissioning.

[0124] In certain embodiments, roles define the priority level of control device capabilities. For example, roles may be arranged in a hierarchy, where the actions of some users have higher priority than the actions of other users with lower priority roles. In this case, roles can be used to resolve conflicting instructions between two users. In a specific example, the building owner role has a higher priority than the tenant or room occupant role. In addition, the role may specify the ability of the user to override the control policy defined in the network controller or other automation system for controlling switchable optical devices. For example, the building policy may require that all windows in the building enter a blackout state when the outside temperature exceeds 100°F. Most user roles do not have the authority to override this policy and make one or more windows transparent at this temperature. However, users with the role of "super user" or "network administrator" may be allowed to selectively override this policy. To the extent that the role allows coverage, the coverage may be limited to a defined time period, such as a few minutes to a few hours.

[0125] In some implementations, there are both qualitative and quantitative elements for the security model. A "role" is qualitative because it defines the operations that can be performed and, in some cases, the classes of objects that can be controlled (e.g., a particular type of device). There is also a "resource" element (more quantitative in nature) that defines individual object instances that can be controlled. In general, roles and resources can be divided like this: a user can perform A, B, and C (role) operations on X, Y, and Z (resources). In a specific example, the "building tenant" role is only allowed to change the shading state of windows under the control of building tenants. Building tenants cannot modify or create rules, and cannot accept or reject adaptive proposals. A specific individual with a building tenant role is allowed to act in that role only for specific resources assigned to them (e.g., window resources in the room where a specific individual works). In contrast, an individual with a network administrator role may be allowed to generate and modify rules, including rules that are automatically presented using adaptive control, override actions requested by individuals with lower roles, and the like. The resources available to such individuals may include all devices in one or more buildings, or alternatively all devices on a specific floor or other area of ​​a building.

[0126] In some embodiments, creating roles for users is accomplished by visiting the site and talking to the building owner or manager and programming the application appropriately on the web server at that time. Alternatively, the building owner or manager may provide a file that lists all of the users who will be given access to the application and the role of each user. In various embodiments, these user roles are applied after the device is commissioned.

[0127] The following is an example of a user role hierarchy for a window control application:

[0128] 1. Building Manager

[0129] 2.1st floor administrator; 2nd floor administrator; ... Nth floor administrator

[0130] 3. Room 1 occupants, room 2 occupants, ... room M occupants

[0131] The following is an example of permissions provided based on user roles in a window control application:

[0132] Recommissioning devices (reorganizing groups, changing device IDs or other properties)

[0133] Debug devices (create groups, inventory devices, verify and / or test devices)

[0134] Set rules and / or procedures (change a rule or condition—for example, replace a threshold of 300 Lux with a threshold of 500 Lux).

[0135] Manual or direct control of a device (e.g. Figure 4A , Figure 4B , Figure 5A and Figure 5B The screenshots are described, as well as Figure 1B Schematic diagram of the diagram).

[0136] Use apps to define rules and procedures

[0137] Device control software applications as described herein may provide users with the ability to select, create and / or modify rules. In some embodiments, applications that provide access to windows or other devices provide a user interface through which user input is interpreted to create, modify and / or delete rules and programs for controlling such devices. Application functions and actions provided by permissions may be Figure 2 FIG7 and FIG7A are portions of the operation 209 shown in the flowchart. FIG. 8A to FIG. 8B Screen shots are presented depicting a user interface that allows a remote user to interact with rules and / or create rules.

[0138] In some cases, at least two types of rules are provided via application: schedule-based rules and sensor-based rules. More generally, these types of rules can be characterized as time rules and environmental rules. Some environmental rules may not come directly from local sensors. As an example, weather conditions determined from a weather information source at the location of a window can be used as the source of environmental rules. In some cases, both time conditions and environmental conditions are included in the rules. In schedule-based rules, certain control or monitoring events are performed according to the schedule specified in the rules. In sensor-based rules, the output from the sensor acts as an independent variable and the device state (e.g., the shading level in the window) is a dependent variable. Further information and examples about sensor-based and schedule-based rules are described in U.S. Patent Application No. 13 / 449,235 [Agent File No. SLDMP035] filed on April 17, 2012 and with S. Brown et al. as inventors, which is incorporated herein by reference in its entirety. Any rule (schedule-based, sensor-based or otherwise) can be composed of two or more conditions, which can be coupled, for example, with Boolean expressions. Other rules include only a single condition.

[0139] According to various embodiments provided herein, device control rules can be part of a hierarchy where a "program" is composed of "rules", and a rule has one or more "conditions" and a "control state". For example, the condition of a rule (which acts as an independent variable) can take schedule information and / or sensor information. In other words, the rule takes the schedule and / or sensor information as independent variables and determines the control state as a dependent variable.

[0140] Conditions are components of rules. If one or more conditions of a rule are met, the "control state" of the rule is applied to one or more devices associated with the condition. Conditions in rules are met or not met based on a comparison of inputs to thresholds, triggers, etc. built into the condition. The comparison can be a simple relationship (e.g., direct equality of input independent variables, < or > tests) or a more complex evaluation of the inputs (e.g., linear or nonlinear expressions, graphs, lookup tables, etc.). In some cases, a condition may provide multiple thresholds, such as a bracketed range (e.g., the room temperature must be between 64°F and 72°F for the condition to be met).

[0141] The input of the condition can be time, environment, user-driven, etc. The time input can be the time of the year (e.g., season), the time of the month, the time of the week (e.g., weekdays and weekends), the time of the day (e.g., noon, sunrise, sunset). The environmental input can be based on external information and / or any of a variety of sensors installed in or near the building structure, which operate under the control of the application. Such sensors include light sensors for monitoring irradiance inside or outside the building structure under the control of the application, temperature sensors for monitoring temperature inside or outside the building structure under the control of the application, occupancy sensors located in controlled rooms or other locations in the building structure, etc. The environmental input can also include input from content generated inside or outside the building structure. Such content can include weather information from commercial and / or government sources, power consumption / availability information provided from local utilities or government sources (or from within the building structure itself (e.g., determined by a building management system)), etc. The user input of the condition includes manual control input provided via a user interface for the device control application, and new user-defined conditions received by the application from the user interface.

[0142] Some rules are composed of a single condition. If the condition is met, the rule control state is applied. Some rules are composed of two or more conditions. This multi-condition rule triggers its control state only when a certain combination of its constituent conditions is met. In some embodiments, the constituent conditions are linked by Boolean operators such as "and", "or", "and non", "exclusive or" or another operator. In the case of the "and" operator, in order to apply the control state, each of the two conditions linked by the operator must be met. In the case of the "or" operator, in order to trigger the control state, any one of two or more associated conditions must be met. In some embodiments, the rule weights two or more constituent conditions to determine whether the control state is applicable. For example, "condition 1" can be given a weight of 75%, and "condition 2" can be given a weight of 25%. Weights can be applied as coefficients, connection strengths (such as in neural networks), etc.

[0143] The control state applied by the rule can drive the optical transition of the optically switchable device or maintain the optical conditions in such a device. For example, depending on the control state determined by the rule for controlling the shading level, the shading level in the electrochromic window can be maintained in an existing state or transformed to a different state. Other optical states that can be maintained or adjusted as the control state evaluated by the rule include opacity, reflectivity, color, etc. Other control states of the rule include power consumption of one or more devices controlled by the rule, sensor monitoring of the device under the rule control, etc. In some embodiments, the control state can force power consumption to drop to a specific level. This may require reducing air conditioning to the building structure, which in turn may require shading the electrochromic window to a specific level and / or requiring the lights to be dimmed to a specific level. In some embodiments, the control state may require that power consumption information be sent to the utility. In some embodiments, the rule control state can trigger the monitoring of one or more sensors under the control of the rule. The rule may require that sensor information be provided as input to one or more algorithms running on a building management system or a security system. In some cases, sensor information (or conclusions drawn from sensor information) is communicated to an entity that is not associated with the building structure with the sensor. Such an entity may be a private or governmental emergency response organization, such as a local police or fire department.

[0144] Some applications and / or their associated network servers may provide a "program" composed of one or more rules. Within a program, these constituent rules may have different priorities or applicability under different ranges of conditions. For example, Rule 1 may apply in winter, and Rule 2 may apply in all other seasons. In another example, Rule 1 will apply when its conditions are met, and Rule 2 will apply when its conditions are met and the conditions of Rule 1 are not met. In other words, Rule 1 has a higher priority than Rule 2. See below for more information. Fig. 8A and Figure 8B and related discussions.

[0145] In some embodiments, the application applies one or more maintenance rules. In this case, the application is programmed to alert the user through the user interface when maintenance issues arise. For example, it may be noted that a window takes too long to shade. In some embodiments, the window or other device will be displayed in a dashboard presented on the user interface.

[0146] Description of the sample screenshots

[0147] As explained, the window control application allows the user to interact with the device via a user interface. A "graphical user interface" (GUI) or "user interface" allows the user to interact with an electronic device via an image or text command. As used herein, a user interface is a part of an application or is provided via an application. The user interface can be used in computers, handheld devices (such as smart phones or tablet computers), portable media players or gaming devices, home appliances, and office devices. The graphical user interface represents the information and actions available to the user by graphical icons and visual, auditory or other sensory indicators or auxiliary symbols (such as position, indentation, color, symmetry, audible tones, and patterns, etc.). Any user interface (whether a graphical interface or other interface) can use text elements, typed command labels or text or keyboard navigation. In a graphical user interface, user actions can be performed by direct manipulation of graphical elements. In some embodiments, the interface also allows voice-activated interaction. This may be appropriate for disabled users and / or users who cannot conveniently interact with the GUI tactilely (e.g., users driving vehicles). Speech recognition tools (such as the DragonNaturally Speaking product from Nuance Communications) can be used to achieve this purpose.

[0148] A graphical user interface uses a combination of techniques and devices to provide a platform with which a user can interact for tasks of collecting and generating information. Various graphical and / or textual features may be employed to aid user interaction with an application that deploys a user interface. Examples of such features include windows, icons, menus (including drop-down menus), pick lists, pointing devices, and the like. Icons such as slide bars, radio buttons, toggle switches, and the like may provide graphical control mechanisms.

[0149] Some interaction modes use a touch screen or other physical input device to control the position of the pointer and present information organized in windows and represented as icons. Available commands are compiled together in menus, and gestures are made using a pointing device to perform actions. A window manager facilitates interaction between windows, applications, and the window system. The window system handles hardware devices such as touch screens, pointing devices, and graphics hardware, as well as the positioning of the pointer.

[0150] In computing devices, these elements can be modeled by a desktop metaphor to produce a simulation sometimes called a desktop environment, in which a display represents a desktop, and documents and folders of documents can be placed on and removed from the desktop. Window managers and other software combine to simulate desktop environments with varying degrees of realism.

[0151] In the examples of user interfaces described below, the user interface includes a set of screens and associated controls and functionality that can receive user input and respond to the input by taking certain actions. Some actions, whether triggered by user input or otherwise, result in changes to the information displayed on the display screen. Such changes can involve highlighting of different features, movement of sliders, transitions to different windows, etc.

[0152] As used herein, the concept of a user interface incorporates not only the information displayed on the screen at any given moment, but also the associated logic and algorithms for displaying the information. These logic and algorithms receive as input, user input, parameter values ​​from sensors or other monitoring devices used by the network window controller, external source feeds, schedule information, etc. In a related embodiment, the information displayed by the user interface may include textual information, graphical information, audio information, tactile information, olfactory information, video information, etc.

[0153] FIG. 4A to FIG. 4G , FIG. 5A to FIG. 5H , FIG. 6A to FIG. 6E , 7A to 7E and FIG. 8A to FIG. 8B Screen shots of various user interfaces that may be employed with certain window controller applications are presented. The user interfaces are shown from the display of a tablet device or smart phone. As mentioned, other types of remote devices may be substituted. In addition, while the screenshots show user interfaces implemented via a touch screen, other interface selection mechanisms such as pointer-based interfaces may also be employed. Further, the interface features depicted in the screenshots are for illustration only, and various other user interface implementations may also be appropriate.

[0154] FIG. 4A to FIG. 4G A “home screen” of an application running on a tablet-type mobile device and displayed on a display device 402 is depicted. Figure 4A A specific implementation of a home screen is presented. FIG. 4B to FIG. 4G Depicted Figure 4A Some variations of the home screen depicted in .

[0155] Figure 4A The display shown in has certain buttons located at the periphery of the main screen. These buttons enable navigation to other screens in the user interface and / or activation of certain functions allowed by the application. In the upper left corner of the display screen, a button 404 containing a partial circle with an arrow enables the user to return to the previous screen. In the upper right corner of the main screen 402, a button 406 containing a wrench and screwdriver icon allows activation of configuration functions. The configuration functions allow, for example, entering an IP address for an associated window controller, debugging various windows, sensors, window controllers, etc. As described below, in Figure 4GA screenshot depicting some features of the user interface for configuring functionality is depicted in FIG. At the bottom of the home screen 402, three additional buttons with icons are displayed. The leftmost of these buttons is the home button 408, which when activated returns the application to a context menu such as 4A to 4F 408. Typically, the home button is visible from all other screens of the application. Such other screens may include, for example, configuration screens, group options screens, schedule program screens, etc. To the right of the home button 408 is a "Programs" icon and associated button 410. Selection of this button takes the user to a menu that provides functions for creating, viewing, editing, and / or deleting specific window control programs (such as sensor input-based programs (see Fig. 8A and Figure 8B ) and timetable-based procedures (see 7A to 7E ))). To the right of the program button 410 is a group button 412, which, when selected by the user, displays a screen that allows the user to debug the device and / or define a group containing one or more devices. FIG. 6A to FIG. 6E An example of such a group screen is described in .

[0156] Inside the main display screen, a suitable background image may be depicted. In the illustrated example, a building belonging to Soladigm Corporation (now View Corporation) is depicted. In various embodiments, the user is allowed to customize the background image presented in the main screen. For example, the user may enter a geographic location specified by an address, zip code, latitude and longitude coordinates, etc. Many other possibilities will be apparent to those skilled in the art. For example, the background may be a video feed from a security camera or other remote monitoring tool.

[0157] exist Figure 4A 4 is a main screen shown in FIG. 4. The left side of the inner area of ​​the main screen is two panels, the leftmost is a control and status panel 420, and the right side of the control and status panel is adjacent to the environment panel 422. The control and status panel provides status and control functions for a "group", which is identified by the group name presented somewhere in the "group subpanel" 424. In some embodiments, multiple available groups are made visible in the application. In some embodiments, these can be selected via a pick list or other interface function, as described below. Figure 5G Depicted in.

[0158] Below the group identifier 424 is a control subpanel 426 that contains buttons that allow the user to select an automatic mode or a manual mode. The automatic mode provides control via one or more preset algorithms, programs, or rules resident on (or available to) the network window controller. Examples of such programs include schedule-based programs and sensor-based programs. In some embodiments, the automatic button of the control subpanel 426 is implemented as a drop-down menu or selection list of available automatic programs that the user can select, such as in Figure 5H In the embodiment shown.

[0159] In sub-panel 426, a "manual" mode button is displayed as an alternative to the "automatic" mode button. That is, at any time, only one of the two buttons is selected. Figure 4A In the screenshot depicted in , the manual mode button is selected. When manual mode is selected, the user is presented with options for controlling the appropriate optical properties of the windows in the currently selected group. In the depicted example, four check boxes 428 are presented to allow the user to select any of these check boxes. Each selection check box specifies the shading level of the windows in the currently selected group. When the leftmost box of these boxes is selected, one or more windows in the group are placed in a transparent state. When the rightmost button is selected, one or more windows are placed in the state with the deepest shading. The middle button allows the user to select an intermediate state between the most transparent state and the deepest shading state. Other manual control features are presented in some embodiments. In one example, a lighting dimmer function is presented in the user interface of the application for manual control.

[0160] Continuing down in the control status panel 420, there is a status sub-panel 430 that depicts the current state of one or more windows under the currently selected group. In this example, each available shading level (there are four shading levels in this example) has its own icon. Typically, at any given time, only one of these buttons will be highlighted, and this indicates which available shading level the window is currently in. When the window transitions from one shading level to another, there may be an arrow, as shown in the depicted embodiment, illustrating the transition from one state to another. When the window reaches the selected shading level, the arrow disappears.

[0161] Continuing down in the control and status subpanel 420, an external source feed subpanel 432 is shown. In the depicted embodiment, selection of this button allows the user to identify external content sources that can be displayed or otherwise provided to the application. For example, the user can select a local weather information source such as the Weather Channel TMTo provide input to the application. Such input may be displayed in a window associated with the sub-panel 432 and / or used to provide weather information, which may be an input parameter of one or more programs or rules for automatically controlling the optical state of one or more windows in the selected group. The user may input an external feed by typing in a URL associated with the source. In some embodiments, multiple sources are provided as predefined options through a user interface. In some specific implementations, an external feed is triggered by a user input interpreted as a request for a specific type of external feed. For example, a user may enter his / her geographic information (e.g., zip code) or current location (e.g., via GPS), and the application will automatically provide content customized for the location. Such content may be weather information for the user's location or zip code.

[0162] Finally, in the control and status sub-panel 420, there is an environment button 434. When the user activates this button, the main screen displays the environment panel 422. Figure 4A 4, which appears immediately to the right of control and status panel 420. In the depicted embodiment, environment panel 422 shows the current status of sensors associated with the currently selected group identified in group panel 424. In the depicted example, the interior and exterior temperatures associated with the selected group are displayed at sub-panels 436 and 438, respectively. In addition, the current values ​​of interior and exterior light intensity are presented in sub-panels 440 and 442, respectively. Each of these values ​​depicted in environment panel 422 is provided from one or more associated sensors belonging to the group under consideration.

[0163] Figure 4B A variation of the home screen 402 according to a slightly modified embodiment is presented. In most respects, the home screen and the information displayed are similar to Figure 4A However, sub-panels 426 and 430 of control and status panel 420 contain additional information about the shading levels of the states that can be manually selected by the user. More specifically, the transmittance levels associated with each of these states are digitally depicted in sub-panels 426 and 430.

[0164] In addition, Figure 4B , the environmental panel 422 includes another sub-panel 444 that provides solar heat gain for the selected group. The solar heat gain represents the amount of solar radiation that contributes to the lighting in the room or group under consideration. Similar types of sub-panels can provide other types of useful or general environmental information, such as the relative reduction in heating or air conditioning load due to the current window state, the carbon dioxide savings value associated with the window state, etc.

[0165] Although Figure 4A and Figure 4BDepicts the situation where a user application controlling a network window controller is in manual mode, but FIG. 4C to FIG. 4E The same application is shown running the network window controller in automatic mode. Figure 4C Another view of the home page 402 is provided. As shown here, the environment panel 422 has been removed from the display of the main screen. That is, the panel 422 has been deselected. In addition, the control and status panel 420, and more specifically, the manual / automatic sub-panel 426 has been switched to automatic mode. In this mode, the current state of the window shading is depicted via an icon or graphical representation of the controller 446. Many other current state descriptions can be used instead. In the depicted embodiment, the controller graphic feature 446 has a transparent and shading "light" that is highlighted depending on which of the two available states is currently selected. In one embodiment, when the system transitions from one state to another, the target state "light" in the feature 446 flashes. It should also be noted that the sub-panels 426 and 430 are merged because the current state is effectively depicted by the graphic feature 446.

[0166] Figure 4D The main screen 402 is shown running in a mode where there are multiple available automatic programs that the user can select. Figure 4C As in the screen shot shown, the current state of the windows in the selected group is depicted by a controller icon 446. However, because the network window controller has multiple available programs for controlling the windows in the selected group, an additional menu or selection list 448 is displayed to allow the user to select one of the available programs.

[0167] Figure 4E Presented with Figure 4D 402. One difference is that the selected automatic program has four available states instead of two. These four available states are depicted in the controller icon 446. Figure 4D Another difference is that the environment panel 422 is activated here, similar to Figure 4A .

[0168] Figure 4F Presented with Figure 4E The first difference is that the background display of this home screen has a different image. Figure 4E The second difference between the main screens of the 406F and the 406F is the location of the configuration button 406F at the bottom of the screen rather than in the upper right corner. Pressing the configuration button activates the Figure 4G Another difference is that the manual / auto subpanel 426 has been switched to manual mode. FIG. 4C to FIG. 4EIn the example, the current shading level is indicated by the lit indicator in 446, and the intermediate period of transition is indicated by the flashing indicator. FIG. 4A to FIG. 4E The external source feed subpanel 432 in has been replaced by the weather subpanel 432F.

[0169] Figure 4G A configuration screen 450 is shown activated by the configuration button 406F. The configuration screen allows the user to view and edit information about the devices of the window system, such as IP address, name and description of the profile, software and hardware versions, current date and time, time zone, zip code, etc.

[0170] FIG. 5A to FIG. 5H Depicted with FIG. 4A to FIG. 4E 4. However, these panels are implemented on smartphones with relatively small display screens. Although tablet computers are generally provided with display screens with a diagonal size of about 5 inches to 10 inches, smartphones have display screens with a diagonal size of about 2 inches to 5 inches. Therefore, it is inconvenient to display as much information on a single screen of a smartphone as can be displayed on a single screen of a tablet computer.

[0171] exist Figure 5A , the smartphone display screen 502 displays a status and control panel 520. The panel effectively occupies most or all of the display screen of the smartphone. In the "Group" subpanel 524, a device group is identified. In this case, the group is identified as "Conference Room". Below the Group subpanel is a Control subpanel 526, which includes a check box 528 that allows the user to specify a transparent or shading state for one or more windows in the conference room group. In the depicted specific implementation, the Control subpanel 526 indicates that the application is currently running in manual mode. Immediately below the Control subpanel 526 is a Status subpanel 530. In the depicted screenshot, the Status subpanel shows that one or more windows in the conference room group are currently transitioning from a shading state to a transparent state. At the bottom of the display screen 502 of the user interface of the application is a Home button 508 and a Configuration button 512.

[0172] Now go to Figure 5B , a similar user interface screen is displayed on the display screen 502 of the smart phone. In this depiction, the control and status panel 520 includes a group sub-panel 524, a control sub-panel 526, and a status sub-panel 530. Figure 5BThe control sub-panel 526 depicted in shows that the group "Conference Room 1" has both an automatic mode and a manual mode available. The manual mode is currently selected. In this mode, the user is given four options for setting the shading level. These options are provided by four check boxes 528 in the control sub-panel 526. As depicted, the user has selected an intermediate shading state. Therefore, the state sub-panel 530 indicates that one or more windows in Conference Room 1 are currently transitioning from one intermediate state to a different intermediate state selected by the user. The screen 502 also presents a program button 510.

[0173] Figure 5C Another version of the control and status panel 520 is depicted. In this embodiment, the control sub-panel 526 is merged with the status sub-panel 530 when the selected group (Conference Room 1) is running in automatic mode. In this mode, the user interface of the application presents a menu or pick list 527 of multiple programs that can be used to automatically control one or more windows in Conference Room 1. In the screenshot depicted, the program named "Energy Saving" is running. The current shading state of the windows in Conference Room 1 is depicted by a bar indicator 529, which identifies each shading level as a separate rectangle within the bar. The second rectangle from the left on the bar indicator 529 is currently highlighted, indicating that the second shading level is currently applied to one or more windows in Conference Room 1.

[0174] Figure 5D Describes running in manual mode Figure 5C In manual mode, the panel screen is provided with up and down arrows 531A and 531B, which allow the user to adjust the shading of one or more windows in conference room 1 to a more transparent or darker state.

[0175] Figure 5E Depicted with Figure 4A Environmental panel 522 is similar to environmental panel 422 shown in FIG. Panel 522 includes sub-panels for depicting interior and exterior temperatures (sub-panels 536 and 538, respectively) and sub-panels for depicting interior light irradiance and exterior light irradiance (sub-panels 540 and 542, respectively).

[0176] Fig. 5F Another version of the control and status panel 520 is depicted. In this embodiment, the main screen has four icons and buttons at the bottom of the screen, including a main button 508, a program button 510, a group button 511, and a configuration button 512F. The group sub-panel 524 is provided for the "Conference Room 1" group, and it allows the selection of different groups, such as Figure 5G. The control sub-panel 526 is set to manual mode, which can be switched between automatic (or program) mode and manual mode. The control sub-panel includes four selectable indicators 528 for the shading levels of windows belonging to the "Conference Room 1" group, where the top indicator represents the most transparent level and the bottom indicator represents the darkest shading level. The middle indicators represent intermediate shading levels. The first indicator from the top is currently highlighted, indicating that the most transparent level is currently applied to the windows in Conference Room 1. In this embodiment, each indicator of 528 flashes during the transition to the corresponding shading level. At the bottom of the main screen is the environment sub-panel 534, which allows activation of functions similar to Figure 5E The environment panel 522 shown in .

[0177] Figure 5G A group pop-up screen 544 for selecting one of a plurality of defined windows or groups is depicted, which is activated by a drop-down button 525 in the main screen. In this example, by selecting the "Restaurant" group in the carousel list, the user can simultaneously control multiple devices belonging to the defined restaurant group through the control sub-panel 526 and selectable indicator 528. FIG. 6A to FIG. 6E Features that allow groups to be defined and used are further illustrated in .

[0178] Figure 5H A program pop-up screen 546 is depicted for executing an automatic program to control all devices belonging to the "Restaurant" group (or any other selected window or group) when the program mode is selected in the control sub-panel 526. The program pop-up screen 546 is activated by the drop-down button 527. By selecting a program in the pop-up window 546, such as the "Summer - North" program in this example, the user can apply one of the predefined programs to the devices belonging to the group. Features for defining and using programs are further illustrated below in Figures 7 and 8.

[0179] Fig. 6A and Figure 6B Depicted are two tablet computer screen views presenting the same information about available groups and devices contained within those available groups. As explained, a "group" is typically a collection of devices under the control of a network window controller that interfaces with applications running on remote devices. In some cases, grouping is performed as part of a device commissioning process. Fig. 6A and Figure 6B In the example of , the remote device is a portable tablet computer having a display screen 402. The application is currently displaying a group screen reached by selecting group button 412. The user can navigate to other screens including a home screen and a program screen by selecting buttons 408 and 410, respectively.

[0180] The group screen is shown as having two panels: a group list panel 604 and a group device list panel 606. In the group list panel 604, all available groups accessible by the application are depicted. At any time, only one of these groups is highlighted. Fig. 6A , the "Sensors" group is currently selected. The user may edit the selected group by actuating edit button 608 and then taking the associated actions. For example, the user may rename the group, add or remove devices from the group, etc. The user may also add and remove groups by selecting buttons 610 and 612, respectively. When the user chooses to add a new group, after activating button 610, he or she will be asked to name the group and define the devices included in the group.

[0181] Panel 606 depicts a list of devices included in the group currently selected in panel 604. The user can add or remove members of the device list by activating buttons 614 and 616, respectively. When the user selects button 614, the user interface presents a menu or other feature identifying the types and locations of devices available for inclusion in the selected group. The available devices are typically limited to those that have been previously inventoried as part of the commissioning process.

[0182] Please note that Fig. 6A and Figure 6B The same information is presented, but in a different orientation. Fig. 6A , the group list panel 604 and the group device panel 606 are arranged vertically. Figure 6B In the example, they are arranged horizontally.

[0183] FIG. 6C to FIG. 6E Three views of the group list panel 604 on the smartphone display 502 are depicted as FIG. 6A to FIG. 6B An alternative implementation of an interface for displaying, defining, and editing groups. Figure 6C The group list panel 604 in is activated by the "Group" button 511, and Figure 6C The list in includes the various available groupings. Selecting a specific group provides further information and editing functions for that group, such as Fig.6D An "Edit" button 608 is located in the upper right corner of the screen and allows the user to access a screen for editing the group list. An "Add" button 610 is located in the upper left corner of the screen and allows the user to activate a window to add a new group, such as Fig. 6E as shown in .

[0184] Fig.6D is a screen view of a group information panel 620 for the "restaurants" group, which can be accessed by selecting Figure 6C604 in the group list panel 604. The group information panel 620 displays the name, type, and location of the various devices belonging to the selected group. By activating the "Edit" button 608 located in the upper right corner of the screen, the user can add new devices to the group or remove existing devices from the group. The user can also return to the group information panel 604 by clicking the cancel button 624.

[0185] Fig. 6E is a screen view of the new group panel 630, which can be accessed by clicking Figure 6C 630. The new group panel 630 allows the user to name the new group and select the various devices in the window system. In this example, the new group "Bedroom 1" is named by entering the group name in the indicated group name space 636. The new group panel 630 includes a device sub-panel 638 that provides a complete list of devices in the window system, each of which can be selected by clicking on the item corresponding to the device. As shown here, the "winC1" device has been selected for the group. The device sub-panel 638 displays the name, type, and location of the device. The device list can be filtered by entering keywords in the search box 640. The user can sort the device list by name, type, or location by selecting one of the three buttons 462 representing device properties. The user can save the new group information by clicking on the "Finish" button 634, and / or return to the group information panel 604 by clicking on the cancel button 632.

[0186] 7A to 7E Depicted is a screen view of a user interface for a "schedule based" program for automatically controlling one or more windows in a group according to a preset schedule. The depicted user interface screen allows a user to adjust various parameters associated with the schedule.

[0187] like Fig. 7A , the tablet screen 402 displays a top panel 702, a "time frame" panel 704, and a "set shade state" panel 706. The top panel 702 includes the name of the program ("Autumn" in this example), the type of program (e.g., a schedule program and a sensor program), and the group monitored or controlled by the schedule program. In some embodiments, the user can set the type of program and the group running under the control of the program.

[0188] The time frame panel 704 allows the user to set the start and stop dates associated with the schedule, the start and stop times for each day that the schedule program is active, and the repetition unit associated with the schedule. In the depicted example, the schedule repeats every day. Other alternatives that may be presented to the user include, for example, weekdays and weekends. In some embodiments, the user interface may allow the user to set multiple start and stop times over the course of a day. Thus, for example, while the time frame panel 704 shows only one start time and one stop time. In alternative embodiments, the panel may show two or more start times and correspondingly two or more stop times, such as Figure 7C This is the case in the example shown in .

[0189] In set shade state panel 706, the user is allowed to select a particular shade state to be applied during the time frame set in panel 704. In the depicted example, the user has selected an intermediate shade state for use between 11 a.m. and 2 p.m. Pacific Standard Time during the fall.

[0190] FIG. 7B to FIG. 7E A user interface implemented on a smartphone display 502 for viewing, defining, and editing schedule-based programs is depicted. Figure 7B 824 is shown activated by pressing the program button 510. In this example, the program screen 824 displays a list of user or system predefined automatic programs. The user can begin adding a new program by clicking the "Add" button 820, or begin editing the program list by clicking the "Edit" button 822. By selecting a particular program displayed in the list, the user can access detailed information about the selected program, such as Figure 7C as shown in .

[0191] like Figure 7C, detailed information for a program is shown by a program properties subpanel 826 and a schedule declaration subpanel 828. The program properties subpanel 826 shows the name, type, monitored groups and devices, and repetition interval of a particular program, such as a "Summer - North" program. The schedule declaration subpanel displays the schedule in the program. In this example, the program includes multiple time periods, the first of which is an "off-hours" time period starting at 7:01 PM and ending at 9:00 AM, where the window shading is set to a transparent level, as indicated by a sliding shading bar 829. The program also includes an "early morning" period that begins at 9:01 AM and is associated with a different shading level (not shown). The user can edit the various information displayed in the program properties subpanel 826 and the schedule declaration subpanel 828 by clicking on the "Edit" button 832, such information including, but not limited to, the program name, repetition interval, time period name, start and end times of the time period, and the shading level of the time period. The user can return to the "Back" button 830 by clicking on the "Return" button. Figure 7B Program screen 824. Fig.7D A new program panel 834 is shown that allows a user to define a new program. The user can click Figure 7B 824 to activate a new program panel 834. The user can define the name, type, monitored devices, and recurrence period of the program in the new program panel. In addition, the user can add or subtract time periods for the program, wherein the time periods have the same Figure 7C The same parameters as shown in the schedule declaration subpanel 828. The user can save the newly defined program by clicking the "Finish" button 840, or cancel the operation and return to Figure 7B Program screen 824.

[0192] Fig. 7E An editor program panel 842 is shown that allows the user to define a new program. The user can click Figure 7B 824 to activate the edit program panel 842. Here, the user can delete a program by clicking one of the delete buttons in the edit program panel 842, or start adding a new program by clicking the "add" button 844. By clicking the "done" button 846, the user can return to the Figure 7B Program screen 824.

[0193] like Figure 7BAs indicated in , in the illustrated implementation, the program screen 824 includes an option for the user to program a preferred sleep / wake schedule. As described below with respect to an example use case, a user may be enabled to prepare a daily and / or weekly schedule associated with the user's preferred sleep / wake times. Thus, a user who may live in a residence (e.g., in an apartment or in a detached house) may be enabled to finely adjust the extent to which external light enters the residence, based on, for example, the time of day, the day of the week, and / or the location within the residence. For example, when an optically switchable (shading) window is in a dark shaded state during those times of the day or night when the user wishes to sleep, a better sleeping experience may be provided to the user. Thus, the user's sleeping environment (e.g., bedroom and / or adjacent rooms) may be largely isolated from external ambient light, including from natural sunlight and moonlight as well as external artificial light (street lights, car lights, etc.). In some implementations, the window may be arranged (programmed) to transition from a dark shaded state to a transparent state at a "wake-up" time selected by the user. Thus, the user may be awakened by natural ambient light at a preferred time of the day.

[0194] In an example use case, after clicking the "Sleep / Wake Schedule" option button within the program screen 824, the remote device's display screen 502 may present a "Welcome" screen, such as Figure 7F After clicking the "Start" button 710, the display screen 502 may present a series of graphical user interfaces with which the user may interact to arrange a user's preferred or anticipated sleep / wake schedule. Although the sequence of GUIs may have many variations, in the illustrated use case, the user is first prompted (see Figure 7G ) Enter the user's preferred "early" wake-up time. For example, this time may be related to the user's workday schedule, or, as a further example, to child care / elder care responsibilities. In the illustrated example, the user has selected 9:00 a.m. as the user's "early" wake-up time.

[0195] When the "Next" button is clicked 720 ( Figure 7G ), the display screen 502 may then be as shown Figure 7H , a request is presented to the user to indicate which days of the week the user prefers an "early wake-up" time. Icons 731, 732, 733, 734, 735, 736, and 737 are each associated with a corresponding day of the week and can be configured as a list box so that the user can select any one, two, or more days of the corresponding days of the week.

[0196] In some cases, a user may select a wake-up time that is before sunrise or dusk for the user's location, and some implementations may present information associated with sunrise or dusk. For example, if a user selects a wake-up time of 5:00 AM, and the earliest natural light at the user's location occurs at 6:30 AM, the technology may notify the user that this wake-up time is before sunrise (e.g., "this time is before sunrise"). In some cases, the technology may suggest wake-up times that are closer to or later than sunrise for specific locations and seasons. These implementations may be based on the season of the wake-up time and the predicted sun position at the user's location. Notifications may also change at different times of the year as the position of the sun changes and, in some cases, daylight saving time occurs. For example, 6:30 AM in a certain location in November may be before sunrise, while 6:30 AM in June at the same location may be after sunrise. In another example, when a user selects a time and day to wake up, such as during the day of the week, the user may select a time and day to wake up. Figure 7G and Fig.7I During the sequence, the sunrise and sunset times for a particular time and season can be provided, such as Figure 7M as shown in .

[0197] When the "Next" button 730 ( Figure 7H ), the display screen 502 may then be as shown Fig.7I , a request is presented to the user to enter the user's preferred wake-up time. For example, the time may be associated with the user's non-working day and represent a preferred later "sleep in" wake-up time. In the illustrated example, the user has selected 11:00 am as the user's preferred later wake-up time.

[0198] When the "Next" button 740 ( Fig.7I ), the display screen 502 may then be as shown Figure 7J , a request is presented to the user to indicate which days of the week the user prefers a later wake-up time. Figure 7H , icons 751, 752, 753, 754, 755, 756, and 757 are each associated with a corresponding day of the week and may be configured as a list box so that a user may select any one, two, or more days of the corresponding days of the week.

[0199] When the "Next" button is clicked 750 ( Figure 7J ), the display screen 502 may then be as shown Figure 7K , the user is presented with a request to enter the location or room to which the user wishes to apply the selected schedule. Icons 761, 762, 763, 764 are each associated with a corresponding space (e.g., one or more rooms) of the residence and are configured as a list box so that the user can select any one, two or more of the corresponding rooms.

[0200] When you click the "Next" button 760 ( Figure 7K ), the display screen 502 may then be as shown Figure 7L , a screen confirming that the user's selected entries have been received is presented, and the user can click on the "Finish Setup" button 770 to complete the process. The remote device can store the user's selected entries and / or forward the resulting schedule to a control system (e.g., a network controller or other automated system for controlling optically switchable (shading) windows). The control system can change the shading state of the appropriate windows based on the user's selected entries, for example, maintaining a pitch-black shading during sleep time and transitioning to a transparent state at or shortly before the selected wake-up time. In some implementations, the control system can also control the shading transition to take into account the shading transition time ("characteristic shading transition time") exhibited by the window being controlled. For example, the control system can be configured to start the shading transition before the wake-up time and approximately before the characteristic shading transition time so that the shading transition to the desired transparent state is completed at approximately the set wake-up time. For example, a shading window may take approximately 15 minutes to shade from a pitch-black shading state to a desired transparent shading state for wake-up, and if the desired wake-up time is as follows: Figure 7M As shown in the morning at 9:00, the control system can start the shading transition of the shading window at about 8:45 in the morning, so that the shading window is in the transparent shading state at about 9:00 in the morning.

[0201] When the "Next" button is clicked 770( Figure 7L ), the display screen 502 may then be as shown Figure 7M A screen summarizing the user's selections is shown in . In the illustrated example, additional relevant information is also presented, such as the sunrise / sunset times of the day and a link to the weather forecast.

[0202] It should be understood that the above use cases are representative examples, and many variations are within the contemplation of the present disclosure. For example, several residents may live in a residence and have different sleep / wake schedules, and the residence may include two or more sleeping areas. As another example, a single user may have a more complex schedule than the simple example above. As another example, the user may be prompted to select a preferred time of day for the windows to transition to a dark state. For example, the selected time of day may be close to sunset or shortly after sunset, or, as another example, at the user's preferred bedtime. It should be understood that additional GUI interfaces can be easily provided to accommodate such requirements.

[0203] Thus, in some aspects of the invention, windows are controlled in response to user input to follow a daily and / or weekly schedule for changing the transmittance of the window based on the time of day and / or day of the week. Advantageously, for each day of any week, at a user-input "wake-up" time, the transmittance and / or shading of the window changes from relatively opaque / dark to relatively transparent.

[0204] Optionally, the user can specify that the windows of a particular single room (e.g., one or more bedrooms) will be controlled to conform to a daily schedule, while the windows of other rooms are not so controlled. In addition, in some implementations, the wake-up time input by the user can vary according to the day of the week.

[0205] In some implementations, the sleep and / or preferred wake schedule may include obtaining one or more bedtimes and controlling the transmittance of the one or more optically switchable windows based on the bedtimes. FIG. 7F to FIG. 7M to obtain user input for bedtime using a graphical user interface similar to that shown in . Based on the bedtime selected by the user, the transmittance of the one or more optically switchable windows may be changed to a dark shading state or a darkest shading state at approximately bedtime so that a minimum amount of natural light enters the desired space at and after bedtime. Similar to the above, the control system may begin the shading transition prior to bedtime, with an amount of time in advance that is substantially equal to the transition time from one shading state to a dark shading state or a darkest shading state. The control system may maintain the one or more optically switchable windows in a dark shading state or a darkest shading state from bedtime until wakeup time, which may include not executing other control programs that indicate that the one or more optically switchable windows should be in a different shading state, and thus not changing the transmittance of the one or more optically switchable windows according to these other control programs during this time.

[0206] Some specific implementations provided herein may start shading windows based on the selected wake-up time and the time required to shade the windows to the desired shading state or desired transmittance level. For example, it may be known that an optically switchable device (e.g., a window or door) may take time t1 to shade from shading state 4 (darkest) to shading state 1 (transparent), and the technology provided herein may start shading the optically switchable device at time t1 in advance of the user's wake-up time, so that these windows are in shading state 1 at the wake-up time. In another example, it may be known that an optically switchable device (e.g., a window or door) may take time t2 to shade from shading state 4 (darkest) to a desired transmittance, such as a percentage that is darker than transparent but lighter than the darkest. The technology provided herein may start shading the optically switchable device at time t2 in advance of the user's wake-up time, so that these windows are at the desired transmittance level at the wake-up time.

[0207] In some embodiments, the technology provided herein can be used to shade the optical switchable device of the building to be consistent with the sunrise and / or sunset time of the building location. This can include controlling the optical switchable device to be transformed to the desired shading state, for example, a transparent shading state or an intermediate transparent state at or about the sunrise time of the location within one or more days, weeks or months. Since the sunrise time is adjusted throughout the year, this may also include adjusting the transition time to reach the desired shading state. For example, the sunrise time of the first day can be 6:30 in the morning, and the sunrise time of the subsequent day can be 6:35 in the morning, and the technology herein can control the shading of the optical switchable device to be transformed to the desired shading state near, before or at each such sunrise time (such as 6:30 in the morning of the first day and 6:35 in the morning of the subsequent day). By adjusting the wake-up time to be consistent with the sunrise time of one or more days, the natural light level in the early morning can be provided in the space, which may help to keep the circadian rhythm consistent with sunrise and / or sunset.

[0208] Fig. 8A and Figure 8B A user interface program screen is depicted that allows a user to create or modify sensor-based programs and / or conditions used in such programs. The user interface screen is depicted on a tablet computer display 402.

[0209] Fig. 8AThe screen depicted in FIG. 8 includes a name and priority panel 802, a set of sensor condition panels 804, and a results panel 806. The name and priority panel 802 specifies the name of the program condition in question and its priority. The priority is illustrated in a horizontal bar titled "Order" with an associated pick list of priority values. The sensor condition panel 804 includes a list of sensors that the user has selected for the sensor-based program in question. The user is allowed to select these sensors from the sensors associated with the group to which the program will be applied. In the depicted example, two sensors are identified in panel 804. The program conditions that employ these sensors define conditions for applying the current values ​​from these sensors in an algorithm that compares the sensor values ​​to specific thresholds. In the depicted example, the user has selected an external light sensor as "Sensor 1" and defined a condition in which the output of Sensor 1 is compared to a threshold of 30 foot candles. Similarly, the user has defined an external temperature sensor as "Sensor 2" and defined a comparison of the external temperature to a threshold of 50° F as a condition. In addition, the user has set as a first condition the requirement that the value of Sensor 1 is greater than or equal to the threshold of 30 foot candles. In addition, the user has set a second condition that the value of sensor 2 is less than or equal to a threshold value of 50° F. When both conditions are met (as indicated by the logical operator "AND"), the result specified in panel 806 will apply. As shown, the user has shown this control state as an intermediate shaded state.

[0210] Fig. 8A A screen is depicted that allows a user to define a single sensor-based rule. In various embodiments, there will be two or more sensor-based rules (and possibly schedule-based rules) that are potentially applicable at any time. In general, these rules can act as "programs." These rules can each have their own associated priority that indicates the order in which the rule is to be considered before it is applied. This aspect of the rules is Figure 8B , where a condition panel 810 lists a plurality of rules and their associated priorities and underlying algorithms. In the depicted embodiment, a rule named Winter Sunrise is given a higher priority than a rule named Summer Sunrise. With this arrangement of rules in the program, the network controller and / or associated application will at any time first consider whether the conditions for Winter Sunrise apply. If so, the control state for Winter Sunrise will apply. However, if the conditions for Winter Sunrise do not apply, the application and / or network window controller will consider the conditions for Summer Sunrise. If these apply, the control state for Summer Sunrise will be implemented. Multiple additional rules may be employed to create a list of three, four, five or more such rules. These rules and their associated priorities together constitute a program named "Energy Saving Program," such as Figure 8B808. Panel 808 also shows the status of the program (enabled or disabled), one or more groups that respond to the program, and the type of program. Type options include threshold comparisons, as well as more complex programs, such as those based on linear or nonlinear equations with coefficients, parameter averages, etc.

[0211] Requests from applications are not recognized

[0212] In some embodiments, a request to control or monitor a device via a window control application may be denied or overridden when necessary to implement a policy, a higher priority user's decision, or the like. In some cases, the decision to override is made by arbitrator logic executing on the network (e.g., a network window controller). In some implementations, the decision to override a user's attempted action is communicated to the user via a message delivered via the application's user interface. For a simple example, see Figure 1E and related discussions.

[0213] As described above, some application users may be given higher priority than other users. Such priority differences can provide a convenient way to arbitrate between conflicting commands for controlling the same device but issued from two different application user interfaces, one command from the interface of a low priority user and the other command from the interface of a higher priority user. In various embodiments, commands issued from the interface for lower priority users will not be recognized by the window network. In addition, commands issued from certain users or systems will take precedence over conflicting commands, regardless of whether such users or systems are operated using the window management application. For example, a building manager or other senior building manager may issue commands without using the window control application, and such commands will be given higher priority than any conflicting commands issued from an application used by a lower priority user. Similarly, certain instructions issued from a building management system or other advanced power management system for a building may automatically take precedence over conflicting commands issued from an application.

[0214] The following are some examples of situations in which a user's control requests presented via a device control application are denied or overridden.

[0215] 1. On hot days, receiving a peak load signal from the energy utility, the BMS or facility manager overrides any commands or rules issued via the app and forces all windows to be shaded to save energy on the air conditioning load.

[0216] 2. The facility manager is performing upgrades or maintenance and does not want any disruption caused by spurious commands issued by the application.

[0217] 3. There is a pre-scheduled power outage and the facility manager decides to set all windows to clear to let in more natural light during the power outage.

[0218] 4. The heating system failed in winter, and the facility manager decided to introduce more solar energy into the building.

[0219] 5. The building's air conditioning system is broken and the facility manager decides to block the heat from entering by blacking out all or most of the windows.

[0220] In the list of scenarios for overriding user controls, the first scenario indicates that commands from an application may be overridden when a peak load signal is received from an energy utility. For example, on a day when utility energy consumption is very high due to increased heating or air conditioning loads, the utility may signal its large customers (such as commercial buildings) that energy consumption should be reduced. In some cases, the utility may charge higher energy bills when operating under these conditions. The network controller of a building that receives such a signal may automatically take action to block some or all instructions from the application that are inconsistent with the need to reduce energy consumption. For example, the network controller may automatically force a window to remain shaded, regardless of whether the application issues an instruction to make the window transparent. In other embodiments, a network administrator or other super user may program the network controller to prevent users from overriding low energy settings.

[0221] More complex implementations of network overrides for user actions are also possible. Some must be related to policies for ensuring energy-saving strategies. Other policies may appropriately protect windows or other devices from being damaged under certain conditions. An example of a policy designed to protect or maintain the long life of a window is a policy that requires the window to periodically switch states even if the automatic network controller or user controller does not indicate that a state switch is necessary. For example, it may be desirable to have a window switch the shading state at least every 15 hours in order to extend the life of the window. To do this, the network controller may override a user command that would keep the window in a single state for 15 hours. In one example, the network controller simply cycles the window transitions in the middle of the night to ensure that it transitions at least once every 24 hours. Alternatively, the controller may have the window undergo a transition once before business hours and once after business hours.

[0222] In another example, a network policy may require that a window not be placed in a high shade state when it may be subject to a strong solar radiation energy surge and may experience thermal shock. For example, a policy may require that east-facing windows in a building not be placed in a state greater than a defined shade level during a time period starting 10 minutes before sunrise and ending half an hour after sunrise. Any application-issued rule or manual attempt to configure an east-facing window such that it exceeds the shade threshold during this duration will be rejected by the window controller.

[0223] Example of Adaptive Control

[0224] In certain embodiments, the logic for controlling the optically switchable device infers that a new rule should be suggested or that a change to an existing rule should be suggested. The logic for making such inferences and suggestions may be implemented solely within the control application, or by such application in conjunction with a network controller, and in particular by software executed thereon. Figure 1F A simple schematic representation of such adaptive control is described in and the related discussion.

[0225] Examples of two types of adaptive control are (1) inferring control behavior from user actions (e.g., repeated manual operations), and (2) inferring control behavior from the environment (e.g., by monitoring sensors and / or power consumption). Fig. 9 An example of an adaptive control process is depicted in the flowchart of . As shown there, process 901 begins with the application and / or associated logic detecting a specific event related to the function of a device on the network. See box 903. Such detected events are typically repeated events, from which results or behaviors can be inferred through an inductive process. See box 905. Based on the results or behaviors, the application and / or associated logic proposes rules to the user via a user interface in the application. See box 907. Thereafter, the application and / or associated logic determines whether the user has accepted the proposed rules by responding via the user interface. See box 909. If the user has accepted the suggestion, the network controller (or other appropriate entity) implements the proposed rules. See box 911.

[0226] Reference now Fig.10 , a method 1000 for controlling a window will be described. As described above, each window can be optically switchable, for example, by including a corresponding electrochromic device. The windows can be communicatively coupled to a control system via a network. The control system can be communicatively coupled to a remote device, the communicatively coupling being wired and / or wireless.

[0227] The method includes: at box 1010, in response to user input, using a control system to control: (a) a daily schedule for changing the transmittance of one or more optically switchable windows based on the time of day, and (b) the execution of a corresponding change in transmittance at a first time of the day, the first time of the day corresponding to a first wake-up time selected by the user. The change in transmittance may include changing the shading state of the electrochromic window from dark to transparent. Advantageously, the user input may be performed via a graphical user interface of a remote device communicatively coupled to the at least one control system. In some embodiments, the user input may include a selection of one or more areas within a residence having associated windows, and the execution of the corresponding change in transmittance is performed only for these associated windows.

[0228] Optionally, according to box 1020, the method may also include controlling: (c) a weekly schedule for changing the transmittance of at least one of the windows based on the time of day and the day of the week, and (d) executing corresponding changes in the transmittance according to the weekly schedule, the weekly schedule including at least one day having a second user-selected wake time that is different from the first wake time.

[0229] In some specific implementations, the method may additionally or alternatively include controlling the shading state of the shading window in a manner different from another control program configured to control the shading window. For example, the control system may include one or more baseline control programs, which, in the absence of contrary user input (such as sleep / wake-up schedule input), may control the shading of the shading window based on inputs from sensors, sunny models, sun positions, etc. The method provided herein may override such baseline control programs and / or place the shading window in a shading state different from these baseline control programs. In one example, the one or more baseline control programs may determine that the shading window should be in a specific shading state at a certain time of the day based at least in part on sensor data. Based on the first wake-up time selected by the user provided herein, the shading window should be in a different shading state at the same time of the day, resulting in two desired shading states of the shading window at the same time. To resolve this conflict, implementations herein may override the shade state determined by the one or more baseline control programs and control the shadeable window according to the user selected wake-up time so that the shadeable window is in a different shade state at the same time of the day according to the user selected wake-up time. In one example, the one or more baseline control programs may determine that the shadeable window should begin to transition from the dark state to the transparent shade state at 7:00 a.m. to allow light and heat to enter the space, but the user selected wake-up time is set to 9:00 a.m., which will cause the shadeable window to remain in the dark state from 7:00 a.m. until 9:00 a.m. Therefore, the control system will not execute the one or more baseline control programs and will not cause the shadeable window to enter the shade state according to the one or more baseline control programs. Instead, the control system will cause the shadeable window to enter the shade state according to the user selected wake-up time. In some cases, control of the shadeable window may return to the one or more baseline control programs after the user selected wake-up time and / or outside the user's sleep schedule.

[0230] In certain embodiments, from the perspective of the application or network controller, the adaptive control logic may observe that the user is taking the same action in a consistent manner (e.g., at the same time every day). The adaptive control logic then infers that applicable rules (e.g., rules based on schedules or sensors) can be applied to achieve the consistent results that have been observed. The logic then develops new or modified rules and suggests them to the user via a user interface on a remote device. The application then waits for a response from the user, which chooses to adopt the suggested rules, reject the suggested rules, or modify the suggested rules as allowed in some specific implementations. If the proposed rules are accepted or modified, the adaptive control logic then executes the accepted rules.

[0231] Several examples of adaptive control are as follows.

[0232] 1. Determine the user's date / time preference for light blocking level by monitoring and use it to override the automatic setting. (For example, user Jeff is currently in room 22 on the third floor, and it is observed that he usually prefers the glass to be partially blocked when in this room.)

[0233] 2. Monitor the effect of turning on / off air conditioning to determine the impact of the building's thermal mass on its response to air conditioning, and based on that impact, give commands to turn off / on air conditioning in anticipation of the impact of the building's thermal mass. More generally, the adaptive control logic determines how quickly the temperature in one or more locations within the building responds to changes in driving factors. The driving factors may be air conditioning, heating, and solar radiation allowed in or blocked by windows.

[0234] 3. The adaptive control logic determines that the best setting for the glass state will change due to shadows or reflections from new adjacent buildings or shadows from trees. This effect can be seen from the user

[0235] Infer by adjusting window shading by (or multiple users) to compensate for new buildings or trees.

[0236] Using this inference, the adaptive control logic proposes changes to the shading algorithms in the affected rooms.

[0237] Some additional points may be beneficial regarding the use of adaptive control logic to characterize the response of a building. A command to change lighting or window shading will have an immediate effect on the radiation in a room. In contrast, temperature changes for air conditioning or heating controls are slower. The temperature response is attributed to the thermal mass of the building in part. Unfortunately, thermal mass varies greatly from building to building and even from room to room within a building. To address this issue, the adaptive control logic can monitor the temperature response time after the heating or air conditioning system is powered on or off. Based on this information, the logic can characterize the response time of the building or a portion of a building. Note that the response information from within the building can be obtained with the help of a network controller.

[0238] In another example, the energy model for a particular season suggests that the east-facing windows of a building should be shaded at 9:00 a.m. However, the application and / or network controller determines from monitoring by sensors that the east-facing rooms receive more solar energy than expected before 9:00 a.m. In fact, the rooms become too hot too early and require cooling to maintain a comfortable temperature. Based on this insight, the adaptive control logic determines that it should propose an adjusted shading rule, i.e., the east-facing windows enter a shaded state at 8:30 a.m. instead of 9:00 a.m. to save energy. Assuming the user of the application accepts the suggestion, the application and / or network controller will continue to monitor the early morning temperature in the east-facing rooms. If it is found that there is still too much solar energy flowing through the east-facing windows, the application may propose a further adjustment rule, i.e., shading at 8:00 a.m.

[0239] Sample API for window control application

[0240] In some implementations, an application programming interface (API) is provided for the window control application. Such an API can be used to develop applications for various remote device platforms (including Microsoft Windows TM Through such APIs, internal developers, third-party developers, and system integrators can implement new applications or extend existing applications to monitor and control optically switchable devices on the network.

[0241] In certain embodiments, the API provides portability and interoperability with common mobile, web, and embedded computing environments. The API is not tied to any particular language. Different platforms have different language requirements; for example, Objective C is the typical language for iOS, Java is the typical language for Android, etc. The API can be generalized to any language.

[0242] APIs are often used to create an abstraction layer that separates application-level tasks and presentation logic from the underlying security, storage, communications, networking, and device-specific protocol layers that comprise the management infrastructure of a building or other architectural structure. APIs allow clients to create, delete, view, and modify management objects regardless of their physical location and local access details.

[0243] in conclusion

[0244] Although the foregoing embodiments have been described in some detail in order to facilitate understanding, the embodiments should be considered illustrative and not restrictive. It will be apparent to one of ordinary skill in the art that certain changes and modifications may be practiced within the scope of the appended claims.

Claims

1. A method for controlling one or more optically switchable windows, the method comprising: In response to the first user input, controlling, using at least one control system: (a) a daily schedule for changing the transmittance of at least one of the optically switchable windows based on the time of day, and (b) performing a corresponding change in the transmittance at a first time of day, the first time of day corresponding to a first wake-up time selected by a user.

2. The method of claim 1, wherein the corresponding change in transmittance comprises changing a light-blocking state of the electrochromic window from dark to transparent.

3. The method of claim 1, wherein the user input is performed through a graphical user interface of a remote device communicatively coupled to the at least one control system. The method of claim 3 , wherein the remote device is wirelessly coupled to the at least one control system. The method of claim 1 , wherein the first time of day is close to and not later than the user-selected wake-up time.

6. The method of claim 1, wherein the user input comprises a selection of one or more areas within a residence having associated windows, and the performing of the corresponding change in the transmittance is performed only for the associated windows.

7. The method of claim 1, wherein each window includes an electrochromic device, and changing the transmittance includes changing a light blocking state of the electrochromic device.

8. The method according to claim 1, further comprising: In response to the second user input, controlling, using the at least one control system: (c) a weekly schedule for varying the transmittance of at least one optically switchable window based on the time of day and the day of the week, and (d) performing a corresponding change in the transmittance according to the weekly schedule, the weekly schedule including at least one day having a user-selected second wake-up time, the second wake-up time being different from the first wake-up time.

9. The method of claim 1 wherein the window exhibits a characteristic transition time for transitioning between shading states, and wherein said execution of said corresponding change in said transmittance begins prior to said first wake-up time by an amount of time substantially equal to said characteristic transition time.

10. The method of claim 1, wherein: The user-selected first wake-up time is associated with a first expected sunrise time at the location of the one or more optically switchable windows on a first day, and The change in the transmittance at the first time of day is close to, at, or approximately at the expected sunrise time.

11. The method according to claim 10, wherein: sunrise at the location occurs at the second expected sunrise time of the next day, and The controlling also includes adjusting the first time of day to a second time of day such that the change in the transmittance is close to, at, or approximately at the second expected sunrise time.

12. The method of claim 1, wherein the control system is configured to follow a baseline control procedure under normal circumstances, the method further comprising overriding the baseline control procedure to the extent necessary to follow the daily schedule.

13. The method according to claim 12, wherein: Overriding the baseline control procedure includes the execution of the corresponding change in the transmittance regardless of whether following the baseline control procedure results in the transmittance of the one or more optically switchable windows having a different transmittance during the daily schedule.

14. The method according to claim 13, wherein: The different transmittance is a second light-shielding state at the first time of day, and The at least one control system is configured to avoid changing the transmittance of the one or more optically switchable windows to the second shading state at the first time of day.

15. The method of claim 12, wherein the baseline control program is based at least in part on sensor data and clear weather data, and the daily schedule maintains and changes the transmittance of the one or more optically switchable windows in a manner different from the baseline control program.

16. A control system, comprising: at least one interface communicatively coupled to one or more optically switchable windows; a remote device interface configured to receive a communication from a remote device, wherein the communication includes a first user input; and a logic circuit for controlling, in response to the first user input: (a) a daily schedule for changing the transmittance of at least one of the optically switchable windows based on the time of day, and (b) performing a corresponding change in the transmittance at a first time of day, the first time of day corresponding to a first wake-up time selected by a user.

17. The control system of claim 16, wherein the corresponding change in the transmittance comprises changing a shade state of an electrochromic window from dark to transparent.

18. The control system of claim 16, wherein the user input is through a graphical user interface of a remote device communicatively coupled to the at least one control system.

19. The control system of claim 18, wherein the remote device is wirelessly coupled to the at least one control system.

20. The control system of claim 16, wherein the first time of day is close to and not later than the user-selected wake-up time.

21. The control system of claim 16, wherein the user input comprises a selection of one or more areas within a residence having associated windows, and the execution of the corresponding change in the transmittance is performed only for the associated windows.

22. The control system of claim 16, wherein each window includes an electrochromic device, and changing the transmittance includes changing a light blocking state of the electrochromic device.

23. The control system of claim 16, further configured to: In response to a second user input, control: (c) a weekly schedule for varying the transmittance of at least one optically switchable window based on the time of day and the day of the week, and (d) performing a corresponding change in the transmittance according to the weekly schedule, the weekly schedule including at least one day having a user-selected second wake-up time, the second wake-up time being different from the first wake-up time.

24. A control system according to claim 16, wherein the window exhibits a characteristic transition time for transitioning between shading states, and the execution of the corresponding change in the transmittance begins before the first wake-up time, and the amount of time in advance is substantially equal to the characteristic transition time.

25. The control system of claim 16, wherein the control system is configured to follow a baseline control procedure under normal circumstances, and is further configured to override the baseline control procedure to the extent necessary to follow the daily schedule.

26. A control system according to claim 25, wherein: The overriding of the baseline control procedure includes the execution of the corresponding change in the transmittance, regardless of whether following the baseline control procedure would result in the transmittance of the one or more optically switchable windows having a different transmittance during the daily schedule.

27. A control system according to claim 26, wherein: The different transmittance is a second light-shielding state at the first time of day, and The control system is configured to avoid changing the transmittance of the one or more optically switchable windows to the second shading state at the first time of day.

28. A control system according to claim 25, wherein the baseline control program is based at least in part on sensor data and clear weather data, and the daily schedule maintains and changes the transmittance of the one or more optically switchable windows in a manner different from the baseline control program.

29. A non-transitory computer readable medium comprising instructions for causing at least one control system to perform a method comprising: In response to the first user input, controlling, using the at least one control system: (a) a daily schedule for varying the transmittance of at least one of the one or more optically switchable windows based on the time of day, and (b) performing a corresponding change in the transmittance at a first time of day, the first time of day corresponding to a first wake-up time selected by a user.

30. The non-transitory computer readable medium of claim 29, wherein the corresponding change in the transmittance comprises changing a shade state of an electrochromic window from dark to transparent.

31. The non-transitory computer readable medium of claim 30, wherein the user input is performed through a graphical user interface of a remote device communicatively coupled to the at least one control system.

32. The non-transitory computer readable medium of claim 31, wherein the remote device is wirelessly coupled to the at least one control system.

33. The non-transitory computer readable medium of claim 29, wherein the first time of day is close to and not later than the user-selected wake-up time.

34. A non-transitory computer-readable medium according to claim 29, wherein the user input includes a selection of one or more areas within a residence having associated windows, and the execution of the corresponding change in the transmittance is performed only for the associated windows.

35. The non-transitory computer readable medium of claim 29, wherein each window comprises an electrochromic device, and changing the transmittance comprises changing a light blocking state of the electrochromic device.

36. The non-transitory computer readable medium of claim 29, wherein the method further comprises: In response to the second user input, controlling, using the at least one control system: (c) a weekly schedule for varying the transmittance of at least one of the one or more optically switchable windows based on the time of day and the day of the week, and (d) performing a corresponding change in the transmittance according to the weekly schedule, the weekly schedule including at least one day having a user-selected second wake-up time different from the first wake-up time.

37. A non-transitory computer readable medium according to claim 29, wherein the window exhibits a characteristic transition time for transitioning between shading states, and the execution of the corresponding change in the transmittance begins before the first wake-up time, and the amount of time in advance is substantially equal to the characteristic transition time.

38. The non-transitory computer readable medium of claim 29, wherein the control system is configured to follow a baseline control procedure under normal circumstances, the method further comprising overriding the baseline control procedure to the extent necessary to follow the daily schedule.

39. The non-transitory computer readable medium of claim 38, wherein: Overriding the baseline control procedure includes the execution of the corresponding change in the transmittance regardless of whether following the baseline control procedure results in the transmittance of the one or more optically switchable windows having a different transmittance during the daily schedule.

40. The non-transitory computer readable medium of claim 39, wherein: The different transmittance is a second light-shielding state at the first time of day, and The at least one control system is configured to avoid changing the transmittance of the one or more optically switchable windows to the second shading state at the first time of day.

41. A non-transitory computer readable medium according to claim 38, wherein the baseline control program is based at least in part on sensor data and clear weather data, and the daily schedule maintains and changes the transmittance of the one or more optically switchable windows in a manner different from the baseline control program.

42. A method for controlling one or more optically switchable windows, the method comprising: receiving a first user input of a wake-up time of day; maintaining one or more optically switchable windows in a dark shaded state for a period of time before the wake-up time; as well as The one or more optically switchable windows are transitioned from the dark shading state to a transparent shading state, so that the one or more optically switchable windows are substantially in the transparent shading state during the wake-up time of the day.

43. The method of claim 42, further comprising: receiving a second user input for a bedtime routine; as well as Transitioning the one or more optically switchable windows to the dark shade state allows the one or more optically switchable windows to be substantially in the dark shade state during the bedtime, wherein the time period substantially spans between the bedtime and the wake-up time.

44. The method of claim 43, further comprising preventing the one or more optically switchable windows from transitioning to another shading state during the time period according to one or more other control programs.

45. A control system for controlling one or more optically switchable windows, the control system being configured to: receiving a first user input of a wake-up time of day; maintaining the one or more optically switchable windows in a dark shaded state for a period of time prior to the wake-up time; and The one or more optically switchable windows are transitioned from the dark shading state to a transparent shading state, so that the one or more optically switchable windows are substantially in the transparent shading state during the wake-up time of the day.

46. ​​The control system of claim 45, further configured to: receiving a second user input for a bedtime routine; and Transitioning the one or more optically switchable windows to the dark shade state allows the one or more optically switchable windows to be substantially in the dark shade state during the bedtime, wherein the time period substantially spans between the bedtime and the wake-up time.

47. A control system according to claim 46, wherein the control system is further configured to prevent the one or more optically switchable windows from transitioning to another shading state during the time period according to one or more other control programs.

48. A non-transitory computer readable medium comprising instructions for causing at least one control system to perform a method comprising: receiving a first user input of a wake-up time of day; maintaining one or more optically switchable windows in a dark shaded state for a period of time before the wake-up time; as well as The one or more optically switchable windows are transitioned from the dark shading state to a transparent shading state, so that the one or more optically switchable windows are substantially in the transparent shading state during the wake-up time of the day.

49. The non-transitory computer readable medium of claim 48, the method further comprising: receiving a second user input for a bedtime routine; as well as Transitioning the one or more optically switchable windows to the dark shade state allows the one or more optically switchable windows to be substantially in the dark shade state during the bedtime, wherein the time period substantially spans between the bedtime and the wake-up time.

50. The non-transitory computer readable medium of claim 49, the method further comprising preventing the one or more optically switchable windows from transitioning to another shading state during the time period according to one or more other control programs.

Images