Communicating with and controlling a load control system
By introducing a display screen, communication circuit, and processor into the load control system, combined with physical memory and software instructions, remote monitoring and management of the load control system is realized. This solves the problem of determining and controlling the on/off status and location occupancy of lights in the user environment, thereby improving the system's management efficiency and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- LUTRON TECHNOLOGY COMPANY LLC
- Filing Date
- 2018-06-15
- Publication Date
- 2026-04-17
AI Technical Summary
In the existing technology, it is difficult to remotely monitor and manage the load control system in the user environment, especially to quickly determine the on/off status and location occupancy of lights, which makes it impossible for users to selectively control the load from a remote location.
By introducing a display screen, communication circuits, and a processor into the system, combined with physical memory devices and software instructions, communication with network devices and load control systems is achieved. This allows users to quickly determine the on/off status and location occupancy of lights through a graphical user interface and to remotely control them.
Users can quickly determine which lights are on in the environment and selectively control the on/off status and location occupancy of the lights from a remote location, improving the management efficiency and user experience of the load control system.
Smart Images

Figure CN115379617B_ABST
Abstract
Description
[0001] This application is a divisional application of Chinese invention patent application filed on June 15, 2018, with application number 201880052220.5 and entitled "Communicating with a load control system and controlling a load control system". Background Technology
[0002] For example, user environments in residences, office buildings, or hotels can be configured to include various types of load control systems. For instance, lighting control systems can be used to control lighting loads in the user environment. Motorized curtain control systems can be used to control the natural light provided to the user environment. Heating, ventilation, and air conditioning (HVAC) systems can be used to control the temperature in the user environment. Summary of the Invention
[0003] It may be necessary to communicate with the load control system from the network device and to control the load control system.
[0004] As an example, a device may include a display screen, communication circuitry, and at least one processor, and may further include at least one tangible memory device communicatively coupled to the at least one processor. The at least one tangible memory device may store software instructions that, when executed by the at least one processor, instruct the at least one processor to receive information transmitted by a controller from a communication network via the communication circuitry. The controller may be configured to communicate with lighting control devices, and each lighting control device may be configured to control a corresponding lighting load located within the environment. When executed by the at least one processor, the software instructions may further instruct the at least one processor to: determine, based on the received information, the number of lighting control devices whose corresponding lighting loads are in an on state; display a first graphical user interface on the display screen, the first graphical user interface including lighting device icons representing lighting control devices; and display, via the lighting device icons, a numerical value corresponding to the determined number of lighting control devices whose corresponding lighting loads are in the on state.
[0005] The lighting device icon can be selected by the user. When executed by the at least one processor, the software instructions may further instruct the at least one processor to: detect the user's selection of the lighting device icon; and in response to detecting the selection of the lighting device icon, display a second graphical user interface to the user on the display screen. The second graphical user interface may include the lighting device icon and the numerical value corresponding to the determined number of lighting control devices whose corresponding lighting loads are in the "on" state. The second graphical user interface may further include a corresponding icon for each lighting control device that puts its corresponding lighting load in the "on" state, the corresponding icon may include a first icon corresponding to the first lighting control device that puts its corresponding lighting load in the "on" state.
[0006] The first icon can be selected by the user. When executed by the at least one processor, the software instructions may further instruct the at least one processor to: detect the selection of the first icon corresponding to the first lighting control device; in part, in response to detecting the selection of the first icon corresponding to the first lighting control device, display a third graphical user interface on the display screen to the user, wherein the third graphical user interface enables the user to control the first lighting control device; and in response to detecting interaction between the user and the third graphical user interface, transmit a message to the controller to control the first lighting control device.
[0007] One advantage of such devices is that users can quickly determine which lights in the environment (where the user can be located at a distance from the lights) are on and selectively turn them off (from a remote location).
[0008] As another example, a device may include a display screen, communication circuitry, and at least one processor, and may further include at least one tangible memory device communicatively coupled to the at least one processor. The at least one tangible memory device may store software instructions that, when executed by the at least one processor, instruct the at least one processor to receive information transmitted by a controller from a communication network via the communication circuitry. The controller may be configured to communicate with one or more control devices located within an environment. The control devices may include lighting control devices, each configured to control a corresponding lighting load located within the environment. The control devices may further include an occupancy sensor. At least one of the lighting control devices may be further configured to respond to at least one of an occupancy event and an idle event detected by the occupancy sensor. The occupancy sensor and the at least one lighting control device may be located within the environment.
[0009] When executed by the at least one processor, the software instructions may further instruct the at least one processor to: determine, based on the received information, the number of lighting control devices whose corresponding lighting loads are in an on state; and display a first graphical user interface on the display screen, the first graphical user interface including a first segment and a second segment, wherein the first segment may include lighting device icons representing lighting control devices, and wherein the second segment may include a pane presenting the location of the environment. When executed by the at least one processor, the software instructions may further instruct the at least one processor to: display, via the lighting device icons, a value in the first segment corresponding to the determined number of lighting control devices whose corresponding lighting loads are in the on state; determine, based on the received information, that the occupancy sensor has detected an occupancy event indicating that the location is occupied; and, at least in part based on determining that the occupancy sensor has detected the occupancy event indicating that the location is occupied, display an occupancy indicator indicating that the location is occupied in the pane of the second segment, indicating to the user that the location is occupied.
[0010] When executed by the at least one processor, the software instructions may further instruct the at least one processor to display an icon corresponding to the at least one lighting control device within the pane of the second segment, the icon being selectable by a user. When executed by the at least one processor, the software instructions may further instruct the at least one processor to: detect a selection of an icon corresponding to the at least one lighting control device; in response to detecting the selection of an icon corresponding to the at least one lighting control device, display a control interface on the display screen to control the at least one lighting control device, wherein the control interface may include an actuator; determine the execution of the actuator; and in response to determining the execution of the actuator, transmit one or more messages to the controller, wherein the controller is configured to control the at least one lighting control device based on the one or more messages.
[0011] One advantage of such devices is that users can quickly determine which lights in the environment (where the user can be located at a distance from the lights) are on, determine whether the locations of the lights in the environment are occupied, and selectively turn off the lights in the unoccupied locations while leaving the other lights on.
[0012] The advantages and features described above are merely representative embodiments. These embodiments are not intended to be limiting. Further features and advantages of the embodiments will become apparent from the following description, drawings, and claims. Attached Figure Description
[0013] Figure 1This is a system diagram illustrating an example load control system including control devices.
[0014] Figure 2 This is a system diagram illustrating a system for communicating with and controlling a load control system using a message-passing-based interface.
[0015] Figure 3 This is a system diagram illustrating a system for communicating with and controlling a load control system using a message-based interface and / or an HTTP-based interface.
[0016] Figure 4 This is a system diagram illustrating another system used to communicate with and control the load control system using a message-based interface and / or an HTTP-based interface.
[0017] Figure 5 This is a system diagram illustrating another system used to communicate with and control the load control system using a message-based interface and / or an HTTP-based interface.
[0018] Figures 6A to 6Z and Figure 6AA The example graphical user interface of the application is shown, which allows users to determine information about the load control system and / or control device, and to control the load control system and / or control device.
[0019] Figures 7A to 7B Another example of an application is shown: a graphical user interface that allows a user to determine information about a load control system and / or control device, and to control the load control system and / or control device.
[0020] Figures 8A to 8D Another example of an application is shown: a graphical user interface that allows a user to determine information about a load control system and / or control device, and to control the load control system and / or control device.
[0021] Figures 9A to 9G Another example of an application is shown: a graphical user interface that allows a user to determine information about a load control system and / or control device, and to control the load control system and / or control device.
[0022] Figure 10 This is a block diagram of an instance network device.
[0023] Figure 11 This is a block diagram of the instance system controller.
[0024] Figure 12 This is a block diagram of the instance control target device.
[0025] Figure 13 This is a block diagram of the instance control source device. Detailed Implementation
[0026] Cross-reference to related applications
[0027] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 520,132, filed June 15, 2017; U.S. Provisional Patent Application No. 62 / 553,331, filed September 1, 2017; and U.S. Provisional Patent Application No. 62 / 599,379, filed December 15, 2017, each of which is hereby incorporated herein by reference in its entirety.
[0028] Figure 1 A high-level diagram of an example load control system 100 is shown. The load control system 100 may include a system controller 150 and load control devices for controlling (e.g., directly and / or indirectly) one or more electrical loads in a user environment 102 (also referred to herein as a load control environment). The example user environment / load control environment 102 may include one or more rooms in a house, one or more floors in a building, one or more rooms in a hotel, etc. As an example, the load control system 100 may automatically control lighting systems, lampshades, and heating, ventilation, and air conditioning (HVAC) systems, as well as other electrical loads in the user environment.
[0029] The load control device of the load control system 100 may include a system controller 150, control source devices (e.g., elements 108, 110, 120, and 122 discussed below), and control target devices (e.g., elements 112, 113, 116, 124, and 126 discussed below) (the control source devices and control target devices may be referred to individually and / or collectively herein as load control devices and / or control devices). The system controller 150, control source devices, and control target devices may be configured to transmit (transmit and / or receive) messages, such as digital messages (although other types of messages may be transmitted), to each other using wireless signals 154 (e.g., radio frequency (RF) signals), but wired communication may also be used. "Digital" messages will be used herein for discussion purposes only.
[0030] The control source device may include, for example, an input device configured to detect conditions within the user environment 102 (e.g., user input via a switch, occupancy / vacancy status, measured changes in light intensity, and / or other input information), and in response to the detected conditions, transmit a digital message to a control target device configured to control an electrical load in response to an instruction or command received in the digital message. The control target device may include, for example, a load control device configured to receive digital messages from the control source device and / or system controller 150, and control the corresponding electrical load in response to the received digital messages. A single control device of the load control system 100 may function as both a control source device and a control target device.
[0031] According to one example, system controller 150 can be configured to: receive digital messages transmitted by a control source device, interpret these messages based on the configuration of the load control system, and then transmit the digital messages to a control target device in a control target device for subsequent control of the corresponding electrical load. In other words, the control source device and the control target device can communicate via system controller 150. According to another and / or additional example, the control source device can communicate directly with the control target device without the assistance of system controller 150. The system controller can still monitor such communication. According to another and / or additional example, system controller 150 can initiate digital messages and then communicate digitally with the control source device and / or the control target device. Such communication via system controller 150 may include programming / configuration data (e.g., settings) for the control device, such as configuring scene buttons on a light switch. Communication from system controller 150 may also include, for example, messages directed to the control target device, and said messages contain instructions or commands for controlling the target device to control the corresponding electrical load in response to the received message. For example, system controller 150 may transmit messages to change the light level, change the shading level, change the HVAC settings, etc. These are examples, and other examples are possible.
[0032] Communication between the system controller 150, the control source device, and the control target device can be via wired and / or wireless communication networks as indicated above. An example of a wireless communication network could be a wireless LAN, where the system controller, control source device, and control target device can communicate via, for example, a router local to the user environment 102. This network could be, for example, a standard Wi-Fi network. Another example of a wireless communication network could be a point-to-point communication network, where the system controller, control source device, and control target device use, for example, Bluetooth, Wi-Fi Direct, or CLEAR CONNECT. TMThey can communicate directly with each other via dedicated communication channels. Other network configurations can be used; for example, the system controller can act as an access point and provide one or more wireless / wired-based networks through which the system controller, control source device, and control target device can communicate.
[0033] In order for a target device to respond to a message from a source device, the source device may first need to associate with the target device. As an example of the association process, the source device can associate with the target device by user 142 executing a button on the source device and / or the target device. Execution of a button on the source device and / or the target device places them into an association mode, thus associating them with each other. In association mode, the source device can transmit association messages to the target device (directly or via a system controller). Association messages from the source device may include a unique identifier for the source device. The target device may locally store the source device's unique identifier, enabling it to recognize digital messages (e.g., subsequent digital messages) from the source device, which may include load control instructions or commands. The target device can be configured to respond to digital messages from the associated source device by controlling the corresponding electrical load according to the load control instructions received in the digital message. This is merely one example of how control devices can communicate and associate with each other, and other examples are possible. According to another example, system controller 150 may receive configuration instructions from a user, specifying which control source devices should control which control target devices. The system controller may then transmit this configuration information to the control source devices and / or control target devices.
[0034] As an example of a control target device, the load control system 100 may include one or more lighting control devices, such as lighting control devices 112 and 113. Lighting control device 112 may be a dimmer, electronic switch, ballast, light-emitting diode (LED) driver, etc. Lighting control device 112 may be configured to directly control the amount of power supplied to a lighting load, such as lighting load 114. Lighting control device 112 may be configured to wirelessly receive digital messages (e.g., messages originating from the control source device and / or system controller 150) via signal 154, and to control lighting load 114 in response to the received digital messages.
[0035] The lighting control device 113 may be a wall-mounted dimmer, a wall-mounted switch, or other push-button device for controlling a lighting load, such as lighting load 115. The lighting control device 113 may be adapted for installation in a standard electrical box. The lighting control device 113 may include one or more buttons for controlling the lighting load 115. The lighting control device 113 may include a toggle switch. Execution of the toggle switch (e.g., continuous execution) can switch (e.g., turn off and on) the lighting load 115. The lighting control device 113 may include an intensity adjustment actuator (e.g., a rocker switch or an intensity adjustment button). Execution of the upper or lower portion of the intensity adjustment actuator can increase or decrease the amount of power delivered to the lighting load 115, thus increasing the intensity of the received lighting load from a minimum intensity (e.g., approximately 1%) to a maximum intensity (e.g., approximately 100%) or decreasing it from a maximum intensity (e.g., approximately 100%) to a minimum intensity (e.g., approximately 1%). The lighting control device 113 may include multiple (two or more) visual indicators, such as light-emitting diodes (LEDs), which may be arranged in a linear array and illuminated to provide feedback on the intensity of the lighting load 115.
[0036] The lighting control device 113 can be configured to wirelessly receive digital messages (e.g., messages originating from the control source device and / or system controller 150) via a wireless signal 154. The lighting control device 113 can be configured to control the lighting load 115 in response to the received digital messages.
[0037] The load control system 100 may include one or more other control target devices, such as an electric curtain 116 for directly controlling the covering material 118 (e.g., via an electric motor); a ceiling fan; a desktop or plug-in load control device 126 for directly controlling a floor lamp 128, a table lamp, and / or other electrical loads that can be plugged into the plug-in load control device 126; and / or a temperature control device 124 (e.g., a thermostat) for directly controlling an HVAC system (not shown). The load control system 100 may also, or alternatively, include audio control devices (e.g., a speaker system) and / or video control devices (e.g., devices capable of streaming video content). Similarly, these devices may be configured to wirelessly receive digital messages (e.g., messages originating from the control source device and / or system controller 150) via a wireless signal 154. These devices may be configured to control the corresponding electrical load in response to the received digital messages.
[0038] In addition to being configured to wirelessly receive digital messages via wireless signals and control corresponding electrical loads in response to received digital messages, the control target device can also be configured to wirelessly transmit digital messages (e.g., to system controller 150 and / or associated control devices) via wireless signals. The control target device can transmit such messages to confirm message reception and actions taken, report conditions (e.g., light levels), etc. Similarly, the control target device can also, or alternatively, communicate via wired communication.
[0039] Regarding the control source device, the load control device 100 may include one or more remote control devices 122, one or more occupancy sensors 110, one or more daylight sensors 108, and / or one or more window sensors 120. The control source device may wirelessly transmit or transmit digital messages to an associated control target device via a wireless signal, such as signal 154, to control the electrical load. After pressing one or more buttons on the remote control device 122, the remote control device 122 may send digital messages to control one or more control target devices. The one or more buttons may correspond to a preset scene for controlling, for example, lighting load 115. The occupancy sensor 110 may send digital messages to the control target device in response to occupancy and / or vacancy (e.g., movement or no movement) sensed within its observable area. The daylight sensor 108 may send digital messages to the control target device in response to the amount of light detected within its observable area. The window sensor 120 may send digital messages to the control target device in response to a measured light level received from outside the user environment 102. For example, window sensor 120 can detect when sunlight shines directly into window sensor 120, when it is reflected back onto window sensor 120, and / or when it is blocked by external devices such as clouds or buildings. Window sensor 120 can send digital messages indicating the measured light level. Load control system 100 may include one or more other control source devices. Again, it should be appreciated that the control source devices may also, or alternatively, communicate via wired communication.
[0040] Turning back to system controller 150, this system controller can facilitate the transmission of messages from a control source device to an associated control target device, and / or monitor such messages as indicated above, thereby knowing when the control source device detects an event and when the control target device is changing the condition / state of the electrical load. The system controller can transmit programming / configuration information to the control device. The system controller can also be a source of control messages for the control target device, for example, instructing the device to control the corresponding electrical load. As an example of the latter, the system controller can run one or more clock operations that automatically transmit messages to the control target device based on a configured schedule (e.g., commands for adjusting the lighting control device 113 of lamp 115, commands for directly controlling the motorized blinds 116 of the shading material 118, etc.). For descriptive purposes only, shading will be used herein to describe functions and features associated with motorized blinds. However, it should be recognized that the features and functions described herein are applicable to other types of blinds, such as pleated blinds, horizontal blinds, Venetian blinds, etc. Other examples are also possible.
[0041] According to another aspect of the load control system 100, the system controller 150 can be configured to communicate, for example, with one or more network devices 144 being used by the user 142. The network device 144 may include a personal computer (PC), laptop, tablet, smartphone, or equivalent device. The system controller 150 and the network device 144 can communicate via wired and / or wireless communication networks. The communication network may be the same network used by the system controller and the control device, or it may be a different network (e.g., a wireless communication network using wireless signal 152). As an example, the system controller 150 and the network device 144 can communicate via a wireless LAN (e.g., local to the user environment 102). For example, such a network could be a standard Wi-Fi network provided by a router local to the user environment 102. As another example, the system controller 150 and the network device 144 can communicate directly with each other, for example, using Bluetooth, Wi-Fi Direct, etc. Other examples are also possible, such as the system controller acting as an access point and providing one or more wireless / wired-based networks through which the system controller and the network device can communicate.
[0042] Typically, system controller 150 can be configured to allow user 142 of network device 144 to: determine, for example, the configuration of user environment 102 and load control system 100, such as rooms in the environment, which control devices are located in which rooms (e.g., the location of control devices within the user environment, e.g., which rooms); determine the status and / or configuration of control devices (e.g., light level, HVAC level, shading level); configure the system controller (e.g., change clock schedule); and send commands to the system controller to control and / or configure control devices (e.g., change light level, change HVAC level, change shading level, change preset, etc.). Other examples are also possible.
[0043] Configurable Figure 1 The load control system 100 is configured such that when the network device 144 is local to the system controller, the system controller 150 can only communicate with the device; in other words, the system controller and the network device communicate directly, either point-to-point or via a local network dedicated to the user environment 102 (e.g., a network provided by a router local to the user environment). It may be advantageous to allow users of the network device 144 to communicate with the system controller 150 and control the load control system 100 from a remote location, such as via the Internet or other public or private networks. Similarly, it may be advantageous to allow third-party integrators to communicate with the system controller 150 to provide enhanced services to users of the user environment 102. For example, a third-party integrator could provide other systems within the user environment 102. Integrating such systems with the load control system 100 may be beneficial.
[0044] Now for reference Figure 2 An example system 200 is shown. System 200 may include one or more user environments, such as those represented by user environments 202a and 202b. More specifically, system 200 may be configured to support multiple user environments, of which only two user environments 202a and 202b are shown to aid in the description of system 200. Each user environment may be substantially identical, and each user environment includes corresponding load control systems 210a and 210b, which include corresponding system controllers 250a and 250b and corresponding control devices 220a and 220b (e.g., control source devices and / or control target devices). Typically, the system controllers 250a and 250b and the control devices 202a and 202b of the load control systems 210a and 210b may be functionally similar to those described above. Figure 1The system controller 150 and control devices discussed are used for operation. The difference between each user environment 202a and 202b of system 200 may be that the user environment may be owned by different entities. For example, each user environment may be a residence owned by different users / homeowners, a business, or some combination thereof. For illustrative purposes only, user environments 202a and 202b may be referred to herein as residences owned / rented by homeowners. Therefore, each user environment may include different control devices and different configurations of these control devices and the system controller. In this way, for example, system 200 may include a variety of different properties. Compared to load control system 100, system 200 may include a system for users and / or third parties to interface with load control system 210a / 210b from locations remote from the respective user environments 202a / 202b, such as via the Internet or other private or public networks.
[0045] As shown, each user environment 202a and 202b of system 200 may include corresponding system controllers 250a and 250b (however, a user environment may include more than one system controller) and control devices, collectively referred to as elements 220a and 220b (similarly, system controller 250a and control device 220a may constitute load control system 210a, and system controller 250b and control device 220b may constitute load control system 210b). System 200 may also include one or more message brokers 270 and one or more network devices 280a and 280b. Network devices 280a and 280b may represent computing devices being used by corresponding users of the respective user environments 202a and 202b. For example, network device 280a may be a device being used by the homeowner of user environment 202a (e.g., a telephone, PC, laptop, tablet, smartphone, or equivalent device), and network device 280b may be a device being used by the homeowner of user environment 202b (e.g., a telephone, etc.). As another and / or additional example, network devices 280a and 280b may be integrators providing services to the respective users / homeowners of user environments 202a and 202b. Here, for example, network devices 280a and 280b may each be one or more computing servers. Similarly, system 200 may include multiple network devices 280a and 280b, of which only two are shown for descriptive purposes. According to system 200, network devices 280a and 280b may be remote from the user environment (e.g., not located within the user environment). However, network devices 280a and 280b may also be local to the user environment (e.g., located within the user environment) and communicate with system controllers 250a and / or 250b using message broker 270 as described below.
[0046] System 200 may also include networks 282 and 283, which may include private and / or public networks, such as the Internet. Networks 282 and 283 may be at least partially the same network. Typically, system controllers 250a and 250b may be configured to communicate with message broker 270 via network 282, and each network device 280a and 280b may be configured to communicate with message broker 270 via network 283. By using message broker 270 and other mechanisms described herein, for example, network device 280a may communicate with system controller 250a of, for example, user environment 202a, and interact with control device 220a of said environment. As an example of system 200, a user can communicate with system controller 250a using network device 280a, and through these communications, determine, for example, the configuration of load control system 210a / user environment 202a (e.g., rooms in the environment and the location of control devices within the user environment, e.g., which rooms); determine the status and / or configuration of control device 220a (e.g., light level, HVAC level, shading level); configure system controller 250a (e.g., change clock schedule); and send commands to system controller 250a to control and / or configure control device 220a (e.g., change light level, change HVAC level, change shading level, change preset, etc.). These are merely examples. As another example, network device 280a operated by a third-party integrator can communicate with system controller 250a to determine the status of load control system 210a and control load control system 210a (as described herein), and also use this function to integrate features of load control system 210a with features of another system in user environment 202a that can be controlled by the third-party integrator. As an example, a third-party integrator could be a home security provider, and in response to a problem detected in user environment 202a by a system (e.g., an alarm system) provided by the third-party integrator, instruct system controller 250a to activate lights in the user environment. Other examples are also possible. For instance, the third-party integrator could provide one or more voice / speaker-based devices located in user environment 202a. A user could audibly interface with such devices (e.g., via voice commands), and further communicate with network device 280a (e.g., the third-party integrator's computing server). Network device 280a could then communicate with system controller 250a to control load control system 210a based on how the user interfaces with the voice / speaker-based devices. Alternatively, network device 280a could communicate with system controller 250a to determine the status of load control system 210a, and further communicate with voice / speaker-based devices to audibly report the status to the user. Again, this is just one example. In a similar manner, users and third-party integrators can communicate with any user environment of system 200.
[0047] Referring now more specifically to system controller 250a (which may be similarly configured as system controller 250b), the system may, for example, include one or more general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, microcontrollers, integrated circuits, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any suitable controller or processing device (not shown) (collectively referred to below as processors). The processor of system controller 250a may be configured to execute one or more software-based application programs and / or firmware-based modules, including instructions that, when executed by the processor, may configure the processor to perform signal decoding, data processing, input / output processing, or any other functions and / or features of the system controller as described herein. These features and functions are partly described further below. Figure 2Modules 252 and 260 are represented herein. For example, modules 252 and 260 can be executed as one or more software-based processes. It should also be appreciated that, in addition to and / or as alternatives to software-based instructions and processes, the features, functions, and processes described herein can also be provided by hardware. System controller 250a may also include one or more memory modules / devices (including volatile and non-volatile memory modules / devices) communicatively coupled to the processor. The memory modules / devices may be implemented as one or more external integrated circuits (ICs) and / or one or more internal circuits of the processor. The one or more memory modules / devices may store software-based application programs and may also provide execution space when the processor executes the application programs. System controller 250a may also include one or more communication interface / transceiver / network interface devices (not shown) communicatively coupled to the processor and / or memory devices / modules. The communication interfaces may allow system controller 250a to communicate via one or more wired and / or wireless communication networks. As an example, similarly described for load control system 100, the communication interface may allow system controller 250a to communicate wirelessly with control device 220a. The communication interface may also allow system controller 250a to communicate wirelessly and / or via a wired connection with, for example, a router (not shown), which is local to user environment 202a and provides a local network to the user environment. Through this local network, system controller 250a may communicate with network device 144 local to user environment 202a, and may also communicate with network 282 (e.g., via an Internet service provider, not shown). As further described herein, system controller 250a may also include one or more databases 254. These databases may be flat databases, relational / SQL databases, NoSQL / non-SQL databases, and / or time-series databases, etc., but any form of database may be used. System controller 250a may also include one or more user interfaces, such as a display monitor, keyboard, mouse, speaker, audio receiver, etc. Although system controller 250a is shown to have instance modules 252 and 260 and instance database 254, the system controller may include fewer, other and / or additional modules and databases.
[0048] Referring more specifically to modules 252 and 260 and database 254, database 254 can maintain configuration information for load control system 250a. This information may include, for example: control devices 220a of the load control system; configuration of the user environment 202a, such as rooms in the environment, which control devices 220a are located in which rooms; communication addresses of the control devices required to communicate with the devices; which control source devices can be controlled by / associated with which control target devices; configuration information of the control devices (e.g., button scene configuration, occupancy / idle sensor configuration, etc.); system configuration, such as clock schedules, etc. The database can also maintain status information of the control devices (e.g., error conditions, light levels, shading levels, HVAC levels, power consumption levels, etc.). The database can also maintain event-based information, as described below, which may include records of events occurring within the system. These are merely examples, and other and / or additional or less information is possible.
[0049] For descriptive purposes, module 252 may be referred to herein as a core module or core 252, and may be configured to execute as one or more software-based processes. Core 252 may be configured to act as a communication module between control device 220a and system controller, thereby facilitating and / or monitoring communication between control source devices and control target devices, and storing relevant information in database 254. For example, this information may include changes in which control source devices are associated with which control target devices. The information may also include event-based information, such as (i) events detected by the control source devices (e.g., occupancy / vacancy detected by sensor 110, light levels detected by sensors 108 and 120, detection of switching performed on remote control device 113 or wall panel / switch 113, etc.); (ii) commands transmitted from the control source devices to the control target devices to change settings (e.g., changes in light levels, shading levels, HVAC levels, etc.) based on detected events; and (iii) commands from the control target devices indicating / confirming the changed settings. Core 252 can directly receive status messages from the control device, such as error conditions, light levels, shading levels, HVAC levels, power consumption levels, occupancy / idle status, etc., and store this information in database 254. Core 252 can also run a clock schedule and transmit messages to the control device according to these schedules. Similarly, core 252 can store such changes from the control device and / or acknowledgments from the control device in database 254. As described below, core 252 can also transmit information / messages to module 260 (which may be referred to as the gateway module or gateway 260 for descriptive purposes). Core 252 can receive messages from gateway 260, which may cause the core to change the configuration parameters of the system controller (e.g., clock settings), or transmit messages to the control device (e.g., changes in light levels), or adjust the configuration / operation parameters of the control device (e.g., changing scene buttons on a switch, occupancy / idle sensor configuration), etc. Core 252 can respond to gateway 260 after performing such operations. Core 252 can also receive requests for any information stored in database 254 from gateway 260 as described above, and report the information back to the gateway. These are examples, and core 252 can perform other and / or additional functions and operations.
[0050] The gateway 260 can be configured to act as an interface between system controller 250a and external devices, such as local network device 144 located in user environment 202a and remote network devices 280a and 280b. For example, gateway 260 can receive messages from network device 144 and / or network devices 280a and / or 280b, and route these messages within system controller 250a to, for example, core 252 for execution. Gateway 260 can also receive responses to such messages from, for example, core 252, and route the messages back to network devices 144, 280a, and / or 280b. Gateway 260 can also receive, for example, status and event-based information from core 252, and route the information to network devices 144, 280a, and / or 280b. These are examples, and other examples are possible. To perform such functions and operations, gateway 260 may include an API (Application Programming Interface) server 264, a local shell client (also referred to herein as a shell client) 262, and an MQTT (Message Queuing Telemetry Transport) client 266. Each of the API server 264, local shell client 262, and MQTT client 266 may operate as one or more software-based procedures within system controller 250a, but other configurations are also possible. It should be understood that the names API server, local shell client, and MQTT client used herein are for descriptive purposes only.
[0051] Local shell client 262 can be configured to act as or be used as an interface point for network device 144 local to system controller 250a (e.g., on the same local network as the system controller and / or within user environment 202a). Local shell client 262 can be configured to support a communication connection 234 with network device 144. For example, this connection can be based on TCP / IP (Transmission Control Protocol / Internet Protocol) or UDP / IP (User Datagram Protocol), but other connections can be used. Local shell client 262 can provide a shell-type interface (e.g., a command-line type interface) to network device 144 via the connection. The interface can be a secure shell interface (e.g., using the Secure Shell (SSH) protocol). It should be appreciated that although local shell client 262 is described herein as an interface point for network device 144 local to system controller 250a, network devices on a different network than the system controller (i.e., not on the same local network as the system controller) and / or not within user environment 202a can also use local shell client 262 to communicate with the system controller.
[0052] MQTT client 266 can be configured to act as or be used as an interface point to message broker 270, and therefore as or be used as an interface point to network devices 280a and 280b remotely at system controller 250a. MQTT client 266 can support a communication connection 230a with message broker 270. This connection can be, for example, a TCP / IP-based connection, but other connections can be used. Over this connection, MQTT client 266 can, for example, support an MQTT publish-subscribe messaging protocol via message broker 270, where MQTT client 266 acts as a client of the broker. As further described below, when the term is used in the context of messaging-based protocols, MQTT client 266 can send messages from the system controller to the message broker, and therefore to network devices 280a and / or 280b, by publishing messages to one or more defined topics. Similarly, MQTT client 266 can, for example, receive messages from the message broker originating from network devices 280a and / or 280b by subscribing to one or more defined topics.
[0053] System controller 250a may support an application programming interface (API), which may include a well-defined set of commands and responses (generally referred to herein as APIs or “API messages”) for interacting with network devices 144, 280a, and / or 280b. Service-based applications (e.g., software-based applications) provided by or executed on network devices 144, 280a, and / or 280b may interact with the system controller using the API. API server 264 may serve as a start and end point within system controller 250a for these communications. For example, network devices 144, 280a, and / or 280b may execute one or more software-based applications that provide a defined set of services to a user. These services may be based at least in part on interaction with system controller 250a. For example, network device 144 may provide a software-based application to a user that allows the user to control lights or shades within user environment 202a. Similarly, network device 280a can provide a software-based application to a user, allowing the user to control lights or shading objects from a location outside the user's environment. As another example, as described above, network device 280a can provide alarm-based services.
[0054] To provide such services, network devices can use the API of system controller 250a to deliver API messages to system controller 250a. For example, network device 144 can deliver API messages to a local shell client 262, which can then forward the messages to API server 264, which can then interpret and execute the messages. Similarly, network device 280a can deliver API messages to MQTT client 266 via message broker 270, which can then forward the messages to API server 264, which can then interpret and execute the messages. To execute / interpret API messages, API server 264 can deliver the message (or a transformed form of the message) to core 252 to provide / execute the message, the API server can communicate with database 254 to retrieve and / or store information, and / or the API server can process the message itself. Other instances are also possible.
[0055] Similarly, to provide such services, system controller 250a can transmit API messages to network devices 144, 280a, and / or 280b. For example, core 252 can transmit a message intended for a network device by sending it to API server 264. This information may include a response to a message received from a network device and executed by core 252 (e.g., a message for controlling control device 220a) or a result of said message. This information may include information retrieved by core 252 from database 254 in response to a message received from a network device. Similarly, API server 264 can retrieve information directly from database 254 in response to a message received from a network device. For example, when API server 264 receives information from core 252 and / or database 254, the API server can format the information according to an appropriate API message and then forward the message to local shell client 262 for forwarding to network device 144, and / or to MQTT client 266 for forwarding to message broker 270 and network devices 280a and / or 280b. Other instances are also possible.
[0056] Regarding information flowing from system controller 250a to network devices 144, 280a, and / or 280b, in some cases, this information may be a response to a message received from the network device, as indicated above. In some cases, API server 264 may forward such a response message to both local shell client 262 and MQTT client 266, regardless of the origin of the original message (i.e., from a network device via local shell client 262 or via MQTT client 266). In other cases, depending on which interface the original message originated from, API server may forward the response message to one or the other of local shell client 262 and MQTT client 266.
[0057] According to another aspect of system controller 250a, core 252 can continuously report information based on conditions and / or events originating from load control system 210a to API server 264. For example, core 252 may perform the following operations: (i) report to API server 264 events detected by the control source device from user environment 202a (e.g., occupancy / idleness detected by sensor 110, light level detected by sensors 108 and 120, detection of switching performed on remote control device 113 or wall panel / switch 113, etc.); (ii) report to API server 264 changes in electrical load state that may arise from messages from control source device (e.g., changes in light level, shading level, HVAC / thermostat level / reading, etc.); and (iii) report to API server 264 changes in electrical load state due to clock events. Core 252 may also report to API server 264 changes in the configuration of the load control system, such as the addition of new control devices, changes or creation of the association between control source devices and control target devices, etc. Typically, API server 264 receives any such information from core 252, and API server 264 can forward any such information as API messages to local shell client 262 and / or MQTT client 266, to network device 144 and message broker 270, and thus to network devices 280a and / or 280b. In this way, network devices can learn about the status of load control system 210a in a "real-time" manner without having to query the status of the load control system.
[0058] Now refer more specifically to MQTT client 266 and message broker 270 (note that...) Figure 2A message broker 270 is shown; however, it should be appreciated that system 200 may include multiple message brokers, and network devices 280a and 280b, each of which may include a client process that supports corresponding connections 232a and 232b (e.g., TCP / IP connections, but other connections may also be used) through message broker 270, and may support the MQTT publish-subscribe messaging protocol over this connection through the message broker. Message broker 270 may be one or more computing devices (e.g., one or more computing servers) that act as MQTT message brokers, thereby supporting, for example, the MQTT publish-subscribe messaging protocol. For example, the computing device of message broker 270 may include one or more general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, microcontrollers, integrated circuits, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any suitable controller or processing device, etc. (hereinafter collectively referred to as processors) (not shown). The processor of message broker 270 can be configured to execute one or more software-based applications and / or firmware-based modules, including instructions that, when executed by the processor, can configure the processor to perform signal decoding, data processing, input / output processing, or any other functions or operations that configure message broker 270 to provide the MQTT message broker functionality and operations as described herein. It should also be appreciated that, in addition to and / or as an alternative to software-based instructions and procedures, the features, functions, and procedures of message broker 270 described herein can also be and / or alternatively provided by hardware. Message broker 270 may also include one or more memory modules / devices (including volatile and non-volatile memory modules / devices) communicatively coupled to the processor. The memory modules / devices may be implemented as one or more external integrated circuits (ICs) and / or one or more internal circuits of the processor. The one or more memory modules / devices may store the software-based application and also provide execution space when the processor executes the application. Message broker 270 may also include one or more communication interface / transceiver / network interface devices (not shown) communicatively coupled to the processor and / or memory devices / modules. The communication interface may allow message broker 270 to communicate over one or more wired and / or wireless communication networks, such as networks 282 and 283.
[0059] When the MQTT clients 266 of the respective system controllers 250a and 250b establish corresponding connections 230a and 230b with the message broker 270 and form corresponding MQTT connections with the message broker through connections 230a and 230b, the message broker may, for example, initiate corresponding processes (e.g., software-based processes) 272a and 272b through each MQTT client 266. Similarly, when each network device 280a and 280b establishes corresponding connections 232a and 232b with the message broker 270, the message broker may, for example, initiate corresponding processes (e.g., software-based processes) 274a and 274b through each network device. According to an example of the MQTT protocol, the message broker 270 may receive corresponding API messages from the MQTT clients 266 via connections 230a and 230b at processes 272a and 272b respectively, and forward these messages to processes 274a and / or 274b. Processes 274a and 274b can then forward API messages to network devices 280a and 280b via connections 232a and 232b, respectively. Similarly, message broker 270 can receive corresponding API messages from network devices 280a and 280b via connections 232a and 232b at processes 274a and 274b, respectively, and forward these API messages to processes 272a and / or 272b. Processes 272a and 272b can then forward the API messages to the MQTT client 266 of system controllers 250a and 250b via connections 230a and 230b, respectively. Typically, network devices 280a and 280b can perform authentication processes through message broker 270 before the message broker can forward messages between network devices and system controllers.
[0060] According to an example of the MQTT protocol, when an MQTT client 266 of system controller 250a receives API messages, for example, from API server 264, the MQTT client can forward these messages to message broker 270 via connection 230a by publishing the API messages to a defined topic "A". For example, suppose network device 280a wants to receive information from system controller 250a, then the network device can subscribe to the same topic "A" through message broker 270. After subscribing to topic "A", message broker 270 can forward the API messages received from system controller 250a to network device 280a via process 274a at process 272a via connection 232a. Similarly, for network device 280a to send API messages to system controller 250a, the network device can forward these messages to process 274a via connection 232a at message broker 270 by publishing the API messages to a defined topic "B" (it should be understood that topics A and B can be the same or different). To receive API messages from network device 280a, MQTT client 266 of system controller 250a can subscribe to topic "B" via message broker. After subscribing to topic "B", message broker 270 can forward the API messages received from network device 280a to MQTT client 266 of system controller 250a via connection 230a at process 274a through process 272a. Other instances are also possible.
[0061] Referring now specifically to the above topic, according to one example, each system controller 250a and 250b of system 200 may have an assigned communication address, such as a MAC address (Media Access Control address) (or possibly more than one address). This may be an address assigned to the communication interface or transceiver or network interface device of system controllers 250a and 250b, for example, addresses that support connections to message brokers 230a and 230b respectively (MAC addresses will be used herein for descriptive purposes. However, it is possible to use different addresses assigned to each system controller instead of MAC addresses as discussed herein (e.g., using the topic)). The MAC addresses of each system controller 250a and 250b of system 200 may be different / unique. In this example, system controller 250a may have a MAC address “A1:B1:C1:D1:E1:F1”, and system controller 250b may have a MAC address “A2:B2:C2:D2:E2:F2” (as indicated by labels 222a and 222b). MAC addresses are discussed further below. According to another aspect of system 200, each system controller 250a and 250b may be assigned a unique identifier (ID) value, which may be a random value. In this example, system controller 250a may have a unique ID value “ABC123”, and system controller 250b may have a unique ID value “ABC789” (as shown by labels 222a and 222b). These are merely examples. According to another aspect of system 200, all system controllers 250a and 250b of system 200 may be assigned a common general identifier. In this example, each system controller 250a and 250b has a common general identifier “1201” (as shown by labels 222a and 222b). Again, these are merely examples. (It should be recognized that although system controllers may be described herein as having unique identifiers, MAC addresses, and general identifiers associated with them, these values can generally also be considered as being associated with the corresponding load control system and / or the corresponding user environment of the system controller.) The topics used by system controllers 250a and 250b of system 200 and network devices 280a and 280b may have a certain format, which uses, for example (i) a unique ID value assigned to system controllers 250a / 250b; (ii) a common identifier assigned to all system controllers; and (iii) one of several different topic identifiers / values, such as “request” and “response”, but additional and / or other values may also be used.As an example, the format of a topic used by system 200 may be: " / u / generic identifier / d / system controller ID / topic identifier", where in this example, the generic identifier may be "1201", the system controller ID may be "ABC123" or "ABC789", and the topic identifier may be "request" or "response". Again, this is merely an example and other variations are possible. For instance, a topic used by system controllers 250a and 250b of system 200 and network devices 280a and 280b may have a format that uses, for example, (i) the MAC address assigned to system controllers 250a / 250b; (ii) a generic identifier assigned to all system controllers; and (iii) one of several different topic identifiers / values, such as "request" and "response", but additional and / or other values may also be used. As an example, the format of a topic used by system 200 can be: " / u / generic identifier / d / MAC address / topic identifier", where the generic identifier can be "1201", the MAC address can be "A1:B1:C1:D1:E1:F1" or "A2:B2:C2:D2:E2:F2", and the topic identifier can be "request" or "response". In one aspect, the two examples are similar in that each uses a generic identifier, a unique identifier (e.g., the MAC address of the system controller or a unique ID value assigned to the system controller), and a topic identifier / value. For ease of description, this document will use a topic description example system with the following form: " / u / generic identifier / d / system controller ID / topic identifier". Other variations are also possible.
[0062] According to one example, whenever MQTT client 266 of system controller 250a sends an API message to message broker 270, the MQTT client can publish the API message to the broker along with the topic " / u / 1201 / d / ABC123 / response". Similarly, whenever MQTT client 266 of system controller 250b sends an API message to message broker 270, the MQTT client can publish the API message to the broker along with the topic " / u / 1201 / d / ABC789 / response". If network device 280a, for example, wants to receive API messages from system controller 250a, then, for example, the network device can subscribe to the topic " / u / 1202 / d / ABC123 / response" along with the message broker (it should be understood that network device 280a may only need to subscribe to a portion of this topic, such as " / u / # / d / ABC123 / response", where "#" represents a wildcard value). Similarly, if network device 280a wishes to receive API messages from system controller 250b, for example, the network device can subscribe to the topic " / u / 1202 / d / ABC789 / response" (or simply " / u / # / d / ABC789 / response", etc.) with the message broker. In this way, when the message broker receives API messages published by system controllers 250a and 250b, the message broker can check the associated topic to determine which network devices 280a and 280b may have subscribed to the topic (at least partially) and forward the messages via processes 272a / 272b and 274a / 274b. It can be seen that by using the system controller ID, network devices 280a and 280b can receive API messages from the desired system controllers 250a and 250b.
[0063] According to another example, whenever network device 280a wishes to send an API message to system controller 250a, for example, the network device can publish the message to message broker 270 using the topic " / u / 1202 / d / ABC123 / request". Similarly, whenever network device 280a wishes to send an API message to system controller 250b, for example, the network device can publish the message to message broker 270 using the topic " / u / 1202 / d / ABC789 / request". In other words, network devices 280a and 280b can communicate with the desired system controllers 250a and 250b by using the system controller ID. In order for system controller 250a to receive API messages from network device 280a, the MQTT client 266 of system controller 250a can subscribe to the topic " / u / 1202 / d / ABC123 / request" (or simply, for example, " / u / # / d / ABC123 / request"). Similarly, to enable system controller 250b to receive API messages from network device 280a, the MQTT client 266 of system controller 250b can subscribe to the topic " / u / 1202 / d / ABC789 / request" (or simply, for example, " / u / # / d / ABC123 / request"). In this way, when message broker 270 receives API messages published by network devices 280a and 280b, the message broker can examine the associated topics to determine which system controllers may have subscribed to the topics (at least partially), and forward the messages via processes 274a / 74b and 272a / 272b. Therefore, by using the system controller IDs, network devices 280a and 280b can send API messages to the desired system controllers 250a and 250b.
[0064] As described above, in addition to publishing API messages in response to commands from network devices, system controllers 250a and 250b can continuously publish API messages to message broker 270 when an event occurs within the corresponding load control system. Network devices 280a and 280b that subscribe to receive API messages from the corresponding system controller (e.g., subscribing based on a "response" topic and the system controller's system controller ID) can then continuously receive API messages. If no network device 280a or 280b subscribes to receive messages published by the corresponding system controller 250a and 250b, the message broker can simply discard the messages. Multiple network devices 280a and 280b can also subscribe simultaneously to receive API messages from a given system controller. It can also be seen from the above that by publishing API messages to the message broker using a "request" topic and the appropriate system controller ID of the system controller, network devices 280a and 280b can transmit specific commands to and / or transmit request information from specific system controllers 250a and 250b. Similarly, by subscribing to messages with a "response"-based topic and the appropriate system controller ID from message broker 270, the network device can receive responses to API messages from the corresponding system controller.
[0065] Although System 200 is described in this document as being based on the MQTT protocol, other message-based protocols, such as the Advanced Message Queuing Protocol (AMQP), can be used.
[0066] System 200 uses MQTT messaging-based systems for network devices 280a and 280b to communicate with system controllers 250a and / or 250b of the corresponding user environments 202a and 202b. Now turning to... Figure 3Example system 300 is shown. Although system 200 uses an MQTT-based messaging system for network devices 280a and 280b to communicate with system controllers 250a and / or 250b, system 300 allows network device 380 to communicate with system controllers 250a and / or 250b, for example, using an HTTP (Hypertext Transfer Protocol) based interface. Network device 380 is similar to network devices 280a and 280b in that it can be a device being used by a user (e.g., a homeowner in a user environment) and / or can be a third-party integrator configured to provide services via APIs supported by these controllers based on interactions with the respective system controllers 250a and / or 250b. Specifically, system 300 may allow network device 380 to receive API messages published by the respective system controllers 250a and 250b using an HTTP interface. The information in these API messages may include, for example, event- and status-based information that occurs in the respective load control systems 210a and 210b and is continuously published by system controllers 250a and 250b to message broker 370 (the information may also include API messages responding to messages from network devices). This is discussed below. Figure 4 The instance system 400 illustrates an instance system that further allows network device 380 to use the HTTP interface to transmit API messages to (and receive responses from) the corresponding system controllers 250a and 250b. Although Figure 3 Only one network device 380 is shown, but multiple such devices may exist in system 300.
[0067] System 300 may include one or more message brokers 370 (one shown herein), which may operate similarly to message broker 270 described for system 200. System 300 may also include one or more user environments 202a and 202b and corresponding system controllers 250a and 250b (and associated control devices 220a and 220b) that may have MQTT interfaces with message broker 370, and may also include one or more network devices 280a and 280b that can communicate with the MQTT interface of message broker 370. System controllers 250a and 250b, message broker 370, and network devices 280a and 280b may operate similarly as described for system 200. System 300 may now also include one or more data aggregators 310 (one shown herein), one or more network servers 340 (one shown herein), and one or more network devices 380 (wherein the one or more network devices are denoted as...) that can communicate with network server 340. Figure 3 (Network device 380 in the middle).
[0068] Similarly, although System 300 is described in this document as being based on the MQTT protocol, other message-based protocols, such as the Advanced Message Queuing Protocol (AMQP), can be used.
[0069] For example, the data aggregator 310 may be one or more computing devices (e.g., one or more computing servers), which may include one or more general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, microcontrollers, integrated circuits, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any suitable controller or processing device, etc. (hereinafter collectively referred to as processors) (not shown). The processor of the data aggregator 310 may be configured to execute one or more software-based applications and / or firmware-based modules, which include instructions that, when executed by the processor, may configure the processor to perform signal decoding, data processing, input / output processing, or configure the data aggregator to operate as described herein for any other function. It should also be appreciated that, in addition to and / or as an alternative to software-based instructions and procedures, the features, functions, and procedures of the data aggregator 310 described herein may also be and / or alternatively provided by hardware. The data aggregator 310 may also include one or more memory modules / devices (including volatile and non-volatile memory modules / devices) communicatively coupled to the processor. The memory modules / devices may be implemented as one or more external integrated circuits (ICs) and / or one or more internal circuits of the processor. The one or more memory modules / devices may store software-based applications and may also provide execution space when the processor executes the applications. The data aggregator 310 may also include one or more communication interface / transceiver / network interface devices (not shown) communicatively coupled to the processor and / or memory devices / modules. The communication interfaces may allow the data aggregator 310 to communicate with the message broker 370 and the network server 340 via one or more wired and / or wireless communication networks (not shown). The data aggregator 310 may also include one or more user interfaces, such as a display monitor, keyboard, mouse, speaker, audio receiver, etc.
[0070] Data aggregator 310 may include MQTT client module 312 (also referred to herein as MQTT client), pipe module 314 (also referred to herein as pipe), and filter module 316 (also referred to herein as filter) (it should be understood that the names data aggregator, MQTT client, and pipe used herein are for descriptive purposes only). Each of these modules may be configured as one or more software-based procedural operations within the data aggregator, but other configurations may be used. Although data aggregator 310 is shown as having instance modules 312, 314, and 316, the aggregator may include fewer, other, and / or additional modules. Starting with MQTT client 312, the MQTT client may be configured to support a communication connection 332 with message broker 370. For example, this connection may be a TCP / IP-based connection, but other connections may be used. Over this connection, MQTT client 312 may support the MQTT publish-subscribe messaging protocol through message broker 370, where MQTT client 312 acts as a client of the message broker. When the MQTT client 312 of the data aggregator 310 establishes a connection 332 with the message broker and forms an MQTT connection with the broker, for example, the message broker can begin a response process 376 with the MQTT client 312. According to one example, the MQTT client 312 can subscribe to the topic " / u / 1202 / d / # / response" (where "#" represents a wildcard value) together with the message broker 370. By subscribing to a topic using a common identifier (here, "1201") shared by all system controllers 250a and 250b, the message broker 370 can forward all API messages published to the message broker 370 using the "response" topic from response processes 272a / 272b to process 376. Process 376 can then forward the API messages to the MQTT client 312 via connection 332. It should be recognized that other topics can also be used. For example, MQTT client 312 can also subscribe to the topic " / u / 1202 / d / # / request" (or alternatively, subscribe to the topic " / u / 1202 / d / # / #") together with message broker 370. Here, message broker 370 can also forward all API messages published to message broker 370 by network devices 280a and 280b using the "request"-based topic from the corresponding processes 274a / 274b to process 376 (and thus MQTT client 312). Again, these are merely examples, and other mechanisms can be used by message broker 370 to forward API messages to data aggregator 310.For example, a data aggregator can subscribe to receive API messages from a specific set of system controllers, for instance, by specifying a complete topic used by the respective controller (e.g., " / u / 1202 / d / ABC123 / response" and " / u / 1202 / d / ABC789 / response"). Assuming the data aggregator subscribes only to "response"-based topics from all system controllers 250a and 250b, when the message broker delivers the API message to process 376, the process can then deliver the API message to MQTT client 312 via process 332. Process 376 can also deliver complete topics via API messages, for which the respective system controllers 250a and 250b publish API messages (i.e., the topic may include the system controller ID of the respective system controller, such as " / u / 1202 / d / ABC123 / request" or " / u / 1202 / d / ABC789 / request"). When the MQTT client 312 receives API messages (and associated topics) from the message broker 370, the MQTT client can forward the API messages / topics to the pipeline module 314.
[0071] Pipeline module 314 can be configured to function as, for example, a data cache / message queue that receives API messages and potentially topics from MQTT client 312, processes the API messages (e.g., aggregating several API messages into larger chunks to improve data efficiency), places / writes API messages into the message queue, and controls filter 316 to read API messages from the message queue for further processing. According to another example, pipeline module 314 can be multiple message queues, where MQTT client 312 places API messages into corresponding queues within the queues. In this way, pipeline module 314 can act as a temporary storage device until the API messages are processed by filter 316, as described below. According to another aspect, depending on the number of user environments 202a and 202b / load control systems 210a and 210b in system 300, multiple message brokers 370 may exist, with different message brokers serving different system controllers 250a and 250b. Here, data aggregator 310 may have multiple MQTT clients 312, each targeting a corresponding message broker. Based on this example, the pipeline module 314 can receive API messages from each MQTT client 312 and aggregate these messages into one or more message queues (e.g., one message queue for each MQTT client) for processing by the filter 316.
[0072] Filter 316 can represent one or more modules (e.g., it can act as one or more software-based processing operations) that read and / or receive API messages (and associated topics) from pipeline module 314, filter these API messages based on one or more criteria, and then forward the resulting information to one or more destinations. In one aspect, multiple filter modules can exist that execute at any given time, each analyzing the same API messages read / received from pipeline module 314, and each filter module searching and analyzing specific data and routing the resulting information to appropriate destinations. According to another aspect, assuming pipeline module 314 is multiple message queues, each queue can have a corresponding filter. Filter 316 can be dynamic, as an administrator can change the filters according to the desired configuration of system 300. Filter 316 can filter based on specific fields of the API message itself and / or the topic associated with the corresponding API message. Different filters can be configured to have different functionalities. For example, a filter can operate to simply remove / discard certain types of API messages (e.g., certain conditional information that the network device 380 may not need, which may be generated by system controllers 250a and 250b), and route the remaining API messages (and associated topics) to a destination. Another filter can be configured to operate to search for and detect certain API messages and / or topics, and route these API messages (and associated topics) to a destination. Another filter 316 can be configured to perform operations on API messages read / received from pipeline module 314 (e.g., perform statistical analysis on API messages), and forward the results to a specific destination. It should be recognized that other instances are also possible.
[0073] According to instance system 300, filter 316 may have a communication connection 334 with web server 340. This connection may be based on TCP / IP or UDP / IP, but other types of connections may also be used. Web server 340 may support HTTP / HTTPS (Hypertext Transfer Protocol / Secure Hypertext Transfer Protocol) interfaces on this connection using standard methods (e.g., GET, PUT, POST, DELETE, etc.), but it should be recognized that other interfaces may also be used. When filter 316 receives API messages from pipeline module 314, the filter may discard some messages based on one or more fields of the message and transmit the remaining API messages (e.g., along with their respective topics, such as those published by system controllers 250a and 250b) to web server 340 via connection 334. Filter 316 may accomplish this using standard HTTP methods, such as the PUT command, but other commands may also be used. Similarly, data aggregator 310 may include other filters that route API messages / information to other destinations. As an example, system 300 may also include a data storage system 390, which can receive information from filter 316 and store this information in a database. Database 390 may be a flat database, a relational / SQL database, a NoSQL / non-SQL database, and / or a time-series database, etc., but any form of database may be used. It should be understood that filter 316 may send API messages to web server 340 one at a time, or in batches periodically (e.g., every X seconds or X minutes, every Y messages, and / or when ready to forward Z bytes of messages, etc.). Other variations are also possible.
[0074] As described above, the pipeline module 314 can be multiple message queues, each with a corresponding filter 316. Here, each filter 316 can have a corresponding connection 334 to the network server 340, and can be similarly configured to discard certain API messages received from its corresponding message queue and transmit the remaining API messages to the network server 340 through its corresponding connection.
[0075] In one specific instance, Amazon Web Services can provide one or more operations / functions for a data aggregator 310, where API messages from a message broker 370 can be fed into a KinesisStream consisting of one or more shards, and where lambda functions can obtain API messages from the Kinesis Stream, filter API messages to discard certain messages, and forward the remaining API messages (and related topics) to a web server 340 via HTTP interface 334. Other instances are also possible.
[0076] Turning now to network server 340, the network server may be, for example, one or more computing devices (e.g., one or more computing servers), which may include one or more general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, microcontrollers, integrated circuits, programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any suitable controller or processing device, etc. (collectively, hereinafter referred to as processors) (not shown). The processor of network server 340 may be configured to execute one or more software-based applications and / or firmware-based modules, which include instructions that, when executed by the processor, may configure the processor to perform signal decoding, data processing, input / output processing, or configure network server 270 to function / operate as described herein. It should also be appreciated that, in addition to and / or as an alternative to software-based instructions and procedures, the features, functions, and procedures of network server 270 described herein may also be and / or alternatively provided by hardware. The network server 340 may also include one or more memory modules / devices (including volatile and non-volatile memory modules / devices) communicatively coupled to a processor. The memory modules / devices may be implemented as one or more external integrated circuits (ICs) and / or one or more internal circuits of the processor. The one or more memory modules / devices may store software-based applications and may also provide execution space when the processor executes the applications. The network server 340 may also include one or more communication interface / transceiver / network interface devices (not shown) communicatively coupled to the processor and / or memory devices / modules. The communication interfaces may allow the network server 340 to communicate via one or more wired and / or wireless communication networks (not shown). Through these networks, the network server 340 may support one or more connections 334 with the data aggregator 310 and corresponding connections 336 and 338 with the respective network devices 380. The network server 340 may support HTTP / HTTPS-based interfaces over these connections using standard methods, for example, to communicate with the data aggregator 310 and the network devices 380. In one aspect, the network server 340 may function as an HTTP publish-subscribe server.
[0077] Network server 340 may include network service module 342 (also referred to herein as network service) and worker service module 344 (also referred to herein as worker service) (it should be understood that the names network server, network service, and worker service used herein are for descriptive purposes only). Each of these modules may function as one or more software-based procedural operations within the network server. For example, message queue 348 may connect network service module 342 and worker service module 344. This message queue may be implemented as a Redis cache, but other implementations may also be used. Network server 310 may also include one or more databases, such as subscription database 346. Subscription database 346 may be a flat database, relational / SQL database, NoSQL / non-SQL database, and / or time-series database, etc., but any form of database may also be used. Although network server 340 is shown as having instance modules 342 and 344, message queue 348, and database 346, the server may also have other configurations.
[0078] Starting with subscription database 346, the subscription database may include at least one entry for each system controller 250a and 250b of system 300. As further described below, network service 342 may treat / use the MAC addresses of system controllers 250a and 250b as topics or channels that network device 380 can subscribe to (since the term can be used for HTTP publish-subscribe servers), but this is one example and other examples are possible. Assuming this format is used, subscription database 346 may include the MAC address of each system controller 250a and 250b, and may further include corresponding topics published and / or subscribed to by the system controllers through message broker 370, and associate / correlate the corresponding topics with each MAC address. For example, and as illustrated by label 350, for system controller 250a, subscription database 346 may include the system controller's MAC address ("A1:B1:C1:D1:E1:F1"), and one or more topics used by system controller 250a (here, " / u / 1202 / d / ABC123 / request" and " / u / 1202 / d / ABC123 / response") may be associated with this address. Similarly, for system controller 250b, subscription database 346 may include the system controller's MAC address ("A2:B2:C2:D2:E2:F2"), and one or more topics used by system controller 250b (here, " / u / 1202 / d / ABC789 / request" and " / u / 1202 / d / ABC789 / response") may be associated with this address. A system administrator can configure and maintain this database. Therefore, when a new user environment 202 with a corresponding system controller 250 is added to system 300, the subscription database 346 can be updated to include the MAC address and associated topics of the new system controller. Again, this is one example, and other examples are possible. As another variation, network service 342 can treat / use the system controller IDs of system controllers 250a and 250b as / as topics or channels that network device 380 can subscribe to. Assuming this format is used, the subscription database 346 can include the system controller ID of each system controller 250a and 250b, and can further include one or more corresponding topics published and / or subscribed to by the system controllers through message broker 370, and associate / related these corresponding topics with each system controller ID. For example, the subscription database 346 can be configured as follows:
[0079] System Controller ID ABC123
[0080] theme : / u / 1202 / d / ABC123 / request
[0081] theme / u / 1202 / d / ABC123 / response
[0082] System Controller ID ABC789
[0083] theme : / u / 1202 / d / ABC789 / request
[0084] theme / u / 1202 / d / ABC789 / Response
[0085] Similarly, this is an example, and network service 342 can associate any value / identifier with the corresponding system controllers 250a and 250b and use said value / identifier as a topic or channel, and associate said value / identifier with one or more topics used by the system controllers. For descriptive purposes, network service 342 is described herein as using the MAC addresses of system controllers 250a and 250b as topics / channels.
[0086] The network service 342, as shown, can treat each MAC address listed in the subscription database 346 as a topic or channel that the network device 380 can subscribe to via interface 336. The network server 340 can be configured to operate as follows: The network device 380 may wish to receive API messages published by system controller 250a, for example, to message broker 370. To do this, the network device 380 can communicate with the network service 342 via connection 336 to subscribe to the MAC address of system controller 250a (i.e., subscribe to the MAC address "A1:B1:C1:D1:E1:F1"). When subscribing to a MAC address via the network service 342, the network device 380 can also provide the network service with a notification address (e.g., a Uniform Resource Locator (URL)) to which the network server 340 can publish any API messages. The network service can store this notification address, along with an indication that the network device 380 has subscribed to the MAC address of system controller 250a, in the subscription database 346. In a similar manner, network device 380 can also communicate with network service 342 via connection 336 to unsubscribe from, for example, the MAC address of system controller 250a. The network service can then update subscription database 346 to indicate that network device 380 has unsubscribed from the MAC address of system controller 250a. Network service 342 can store which network devices 380 have subscribed to which channels through other means.
[0087] According to one example, network service 342 can receive API messages (or a subset thereof, if filter 316 has removed certain API messages, such as certain status messages) published by all the aforementioned system controllers 250a and 250b, from data aggregator 310 via connection 334. Similarly, as an example, these API messages may have associated topics in the form of “ / u / 1202 / d / ABC123 / response” and “ / u / 1202 / d / ABC789 / response”. When an API message is received, network service 342 can use configuration information from subscription database 346 to translate the topic into a MAC address. For example, network service 342 can translate the topic “ / u / 1202 / d / ABC123 / response” of an API message from system controller 250a into the MAC address “A1:B1:C1:D1:E1:F1” of system controller 250a. Network service 342 can then determine whether any network device 380 has subscribed to this MAC address. If network device 380 has subscribed to MAC addresses, network service 342 can write, for example, API messages along with their associated topics and / or MAC addresses to message queue 348. Conversely, if no network device 380 has subscribed to API messages, network service 342 can discard the API messages. As an alternative to converting the topics of API messages received from data aggregator 310 to MAC addresses as described above, when network device 380 subscribes to MAC addresses, network service 342 can use subscription database 346 to convert MAC addresses to topics or portions thereof (e.g., converting the MAC address "A1:B1:C1:D1:E1:F1" of system controller 250a to the topic " / u / 1202 / d / ABC123 / response"). When network service receives API messages published by system controllers 250a and 250b from data aggregator 310, network service can compare the topics associated with the messages with the "topics" subscribed to by network device 380. If network device 380 has subscribed to the topic, network service 342 can write the API message, along with its associated topic and / or MAC address, to message queue 348. Conversely, if no network device 380 has subscribed to the API message, network service 342 can discard the API message. Other variations are also possible. Typically, the network service can at least partially associate / correlate the received API message with a message that the network device is expecting to receive, using the MAC address specified by the network device and the system controller ID portion of the topic associated with the API message.
[0088] As described above, network service 342 can receive API messages (or a subset thereof, if filter 316 has removed some API messages) published by system controllers 250a and 250b from data aggregator 310, and can then determine or analyze each API message to determine whether any network device 380 has subscribed to receive the corresponding API message. As another variation, when filter 316 receives API messages from pipeline module 314, the filter can discard some messages (e.g., certain status messages) and then periodically batch the remaining messages into chunks. How the filter batches messages into chunks can vary. Some instances may include (i) batching messages based on time (e.g., batching messages over a time period of X minutes); (ii) batching messages across multiple API messages (e.g., forming chunks of X API messages); (iii) batching messages based on size (e.g., forming chunks of X bytes or less), or some combination thereof. Regarding each batch of API messages, filter 316 can determine the topics associated with the messages and transmit a list of these topics to network service 342 via connection 334. For example, filter 316 can provide the complete topic (e.g., " / u / 1202 / d / ABC123 / Response" and " / u / 1202 / d / ABC789 / Response") or only a part of the topic (e.g., only the system controller ID). Alternatively, filter 316 can access subscription database 346 (as shown via connection 318) and translate the topic into a MAC address and pass the MAC address to network service 342. Other instances are also possible. In any case, filter 316 may not forward actual API messages at this point. After receiving the list of topics, network service 342 can determine for each topic whether network device 380 is currently subscribed to the topic (e.g., by associating the topic with a subscribed MAC address) and transmit an indication of those subscribed (or alternatively, unsubscribed) topics back to filter 316 via connection 334. After receiving this communication from network service 342, filter 316 can discard the unsubscribed API messages from the batched API messages and forward the remaining API messages to network service 316 via connection 334. Upon receiving an API message, network service 342 can write each API message, along with its associated topic and / or MAC address, to message queue 348. Filter 316 and network service 342 can then repeat this process, where filter 316 processes another set of API messages in batches and communicates with the network service to determine which associated topics are currently subscribed to. Other variations are also possible. One advantage of this configuration is that less data needs to be transferred from data aggregator 310 to network server 340, thus providing more efficient communication.
[0089] According to another variation, for example, whenever network device 380 subscribes to the MAC address of system controller 250 via network service 342, network service 342 can translate the MAC address into a topic (e.g., for system controller 250a, the network service can translate the MAC address "A1:B1:C1:D1:E1:F1" into the topic " / u / 1202 / d / ABC123 / response"). Network service 342 can then pass the topic to filter 316 via connection 334, thereby instructing filter 316 to forward any API messages with the corresponding topic. Alternatively, for example, assuming filter 316 accesses subscription database 346, network service 342 can pass the MAC address to filter 316, which can then translate the MAC address into a topic. Other instances are also possible. It should be understood that if multiple network devices 380 subscribe to API messages from the same system controller, network service 342 may communicate with filter 316 only once. Regardless, when filter 316 receives API messages from pipeline module 314, the filter may discard certain messages (e.g., certain status messages) and then compare the subject of the API message with the subject provided to the filter by network service 342 to determine whether network device 380 has subscribed to receive messages. If network device 380 has subscribed to the subject, filter 316 can forward the API message (and its associated subject) to network service 342 via connection 334. Network service 342 can then write the API message, along with its associated subject and / or MAC address, to message queue 348. Conversely, if no network device 380 has subscribed to the API message, filter 316 may discard the API message. Similarly, whenever network device 380 unsubscribes from the MAC address of system controller 250 via network service 342, network service 342 can translate the MAC address into a subject and then transmit the subject to filter 316 via connection 334, thereby instructing filter 316 to stop forwarding the relevant API message. It should be understood that if multiple network devices simultaneously subscribe to the same MAC address, network service 342 may not send this instruction to filter 316 if other devices are still subscribing. Again, this is merely an example, and other variations are possible.
[0090] The process then moves to worker service 344, which can read API messages from message queue 348, determine the notification address of each network device 380 subscribed to receiving API messages, and use the notification address to transmit the API message to the corresponding network device via the appropriate connection 338 (it should be understood that the notification address may differ from the network device's). Worker service 344 may determine the notification address using subscription database 346 as shown above, but other mechanisms may also be used. When transmitting the API message to the network device, worker service 344 may include the MAC address of the topic associated with the API message and / or the corresponding system controller. Thereafter, for example, network device 380 may receive the API message and act on it.
[0091] Although network service 342 and worker service 344 are shown and described communicating via message queue 348, this queue may not be necessary and the two modules may communicate in other ways. However, in one aspect, message queue 348 can provide a mechanism for temporarily storing API messages in situations of high data demand. Moreover, for example, it is not necessarily necessary to use MAC addresses instead of the shown “request” and “response” topics as a mechanism for network device 380 to subscribe to API messages, and network service 342 and network device 380 can be configured to directly subscribe to the shown topics (i.e., network device 380 can subscribe to “ / u / 1202 / d / ABC123 / response”). However, for example, the shown configuration using MAC addresses or variations thereof has at least one advantage: the system controller 250 and subscription database 346 can be updated in the future to use different topics. Using, for example, a MAC address associated with the shown topic (which can be a static value) allows the topic to change without affecting the service applications provided by the network device.
[0092] Similarly, a given network device 380 can subscribe to receive API messages generated by multiple system controllers from network server 340. Likewise, multiple different network devices can subscribe to receive API messages generated by the same system controller from network server 340.
[0093] Turn now Figure 4 Example system 400 is shown. For example, system 400 may be similar to system 300, but in addition to receiving API messages from system controllers 250a and 250b, network device 380 may also use an HTTP interface to transmit API messages to designated system controllers 250a and 250b (e.g., to control the light level in the corresponding user environment).
[0094] According to system 400, network server 340 may further include MQTT client module 472, which can support a communication connection 474 with message broker 370. For example, this connection can be a TCP / IP-based connection, but other connections may also be used. For example, over this connection, MQTT client 472 can support the MQTT publish-subscribe messaging protocol through message broker 370, where MQTT client 472 acts as a client of the message broker. For example, when MQTT client 472 of network server 340 establishes a connection 474 with the message broker and forms an MQTT connection with the broker, the message broker can begin a response process 476 with MQTT client 472.
[0095] To deliver API messages to a specific system controller 250, such as system controller 250a, network device 380 can publish the API messages to network service 342 via connection 336, and specifically, the messages can be published to the MAC address of system controller 250a (i.e., "A1:B1:C1:D1:E1:F1"). Note that since the network device has published the API messages to the MAC address, network service 342 can use subscription database 346 to translate the MAC address into a "request" topic associated with the MAC address (here, " / u / 1202 / d / ABC123 / request"). The network service can then forward the API messages and, for example, the " / u / 1202 / d / ABC123 / request" topic to MQTT client 472. MQTT client 472 can then publish the API messages to message broker 370 via connection 474 using the topic " / u / 1201 / d / ABC123 / request". Additionally, MQTT client 472 can also use message broker 370 to subscribe to a "response" topic associated with the MAC address of controller 250a (i.e., " / u / 1202 / d / ABC123 / response") via connection 474. This topic can also be forwarded to MQTT client 472, for example, by network service 342. By subscribing to the "response" topic of system controller 250a, MQTT client 472 can receive any responses to API messages from system controller 250a.
[0096] Therefore, when process 476 receives an API message from MQTT client 472, message broker 370 can forward the API message to process 272a, which in turn forwards it to system controller 250a (as described above, controller 250a has subscribed to the topic " / u / 1202 / d / ABC123 / request"). For example, when system controller 250a processes the API message, it can generate a response API message, which it can publish to message broker 370 using the topic " / u / 1202 / d / ABC123 / response" as described for systems 200 and 300. Because MQTT client 472 has subscribed to the topic " / u / 1202 / d / ABC123 / response", message broker 370 can forward this response API message from process 272a to process 476, which can then forward the response API message to MQTT client 472 via connection 474. After receiving, for example, a response API message, MQTT client 472 can unsubscribe from the topic " / u / 1202 / d / ABC123 / response" and forward the response API message to network service 342. Network service 342 can then translate the topic of the response API message from " / u / 1202 / d / ABC123 / response" back to the MAC address of system controller 250a and transmit the response API message to network device 380 via connection 336. Similarly, other variations are possible, for example, where network device 380 subscribes to the system controller ID instead of the MAC address.
[0097] According to another aspect of system 400, network server 340 may have multiple (two or more) MQTT clients 472, each MQTT client having a corresponding connection 474 with message broker 370. Network server 342 may use the corresponding MQTT client among the MQTT clients 472 one at a time to transmit API messages from network device 380 to the corresponding system controller 250 and receive responses thereto.
[0098] Although System 400 is described in this document as being based on the MQTT protocol, other message-based protocols, such as the Advanced Message Queuing Protocol (AMQP), can also be used.
[0099] Although systems 300 and 400 are described herein as including a data aggregator 310, other variations of these systems may omit this module. Here, message broker 370 may deliver API messages directly to web server 340. For example, if message broker 370 is receiving a limited amount of information from load control systems 210a and 210b, and / or if there are a limited number of load control systems providing information to the message broker, then data aggregator 310 may not be necessary. Similarly, variations of systems 300 and 400 may include data aggregator 310, but may not necessarily include filter 316, which is configured to remove API messages from the API message stream from pipeline module 314. In other words, data aggregator 310 may forward all API messages received from the message broker to web server 340, rather than removing some messages. However, it should be recognized that the data aggregator and its corresponding filter module can provide an instance mechanism for controlling the rate at which information flows into web server 340 and the amount of data flowing into and needing to be delivered to the web server. Additionally, although system controllers 250a and 250b are described herein as typically forwarding large volumes of information / API messages to the message broker in a non-selective manner via the data aggregator, followed by filtering of this information, the system controllers can be configured to selectively forward only certain API messages to the message broker. However, this may not be necessary, as it could be difficult to access and modify all of these systems if it is later realized that additional information may be needed / wanted to be obtained from the system controller. The system controller's non-selective forwarding of large volumes of information / API messages to the message broker, with the filter module 316 configured to selectively discard certain API messages, has the advantage that if it is later realized that additional information may need to be forwarded by filter 316 or that other information may need to be discarded, the administrator can simply update the filter.
[0100] Turn now Figure 5Example system 500 is shown. For example, system 500 is similar to system 400, but now also allows network device 580 to transmit messages with designated system controllers 250a and 250b using an API different from the API supported by the system controller (i.e., sending messages to and receiving messages from designated system controllers 250a and 250b). In other words, as discussed with respect to system 400, network device 580 can communicate with system 400 using the API supported by system controllers 250a and 250b. According to system 500, network device 580 can communicate with system 500 via an HTTP interface, but now uses a third-party API that can be dedicated to the network device, where system 500 translates between the API supported by the system controller and the third-party API. For descriptive purposes only, messages formatted according to the API supported by system controllers 250a and 250b will be referred to herein as “API messages,” and messages formatted according to the third-party API supported by network controller 580 will be referred to herein as “third-party API messages.”
[0101] Network device 580 is similar to network devices 280a and 280b and network device 380 in that it can be a device being used by a user (e.g., a homeowner in a user environment) and / or can be a third-party integrator configured to provide services based on interaction with the respective system controllers 250a and 250b. Although Figure 5 Only one network device 580 is shown, but multiple such devices may exist, each configured to communicate with one or more system controllers simultaneously.
[0102] Compared to system 400, the data aggregator 310 of system 500 may now include a gateway module 502 (also referred to herein as a gateway) and an API converter module 504 (also referred to herein as an API converter) (it should be understood that the names gateway and API converter used herein are for descriptive purposes only). Although gateway module 502 and API converter module 504 are shown as part of data aggregator 310, these modules may alternatively be provided by one or more other computing devices, such as network server 340 or message broker 370, or by another computing device separate from either message broker 370, data aggregator 310, or network server 340. Each of gateway module 502 and API converter module 504 may operate as one or more software-based processes within the data aggregator, but other implementations are also possible.
[0103] Starting with gateway 502, the gateway can be configured to support a corresponding network communication connection 508 with network device 580 for each system controller 250a and 250b with which the network device is communicating. Gateway 502 can support an HTTP / HTTPS-based interface on connection 508, which network device 580 can use to communicate with gateway 502. As shown, services provided by network device 580 can be based on third-party APIs. Therefore, network device 580 can transmit third-party API messages for specific system controllers 250a and 250b to gateway 502. Gateway 502 can be configured to subsequently forward the third-party API messages to the system controllers, as further described below. Similarly, if a system controller responds with an API message, the response message can be forwarded to gateway 502, which can then forward the response message as a third-party API message to the network device. Similarly, network device 580 can communicate with gateway 502 to subscribe to receive API messages published by specific system controllers 250a and 250b. Gateway 502 can be configured to forward this subscription request to network server 340. When the network server receives API messages from the subscribed system controller, it can forward these messages to gateway 502, which can then forward the messages as third-party API messages to the network device. As one example, gateway 502 may be independent of the specific third-party API used by network device 580, but can be configured such that the format of the third-party API used by the network device needs to be standard-based. As an example, gateway 502 can be configured such that the third-party API may need to be a RESTful (representative state transition) API, where, for example, network device 580 communicates with gateway 502 using standard methods (e.g., GET, PUT, POST, DELETE, etc.), and where system controllers 250a and 250b and control devices 220a and 220b are, for example, considered resources. Again, this is one example, and other examples are possible.
[0104] The system then redirects to API converter 504, which provides API conversion services to system 500. Specifically, API converter 504 may have a connection 510 to gateway 502. When gateway 502 receives a third-party API message from a network device 580 destined for a specific system controller 250a or 250b, the gateway may forward the message to API converter 504. API converter 504 may be configured to subsequently convert the third-party API message into an API message (i.e., an API message supported by the system controller) and forward the API message to the system controller. Similarly, assuming the system controller responds with an API message, the message may be forwarded to API converter 504. API converter 504 may be configured to subsequently convert the API message into a third-party API message and forward the third-party API message to gateway 502, which may then forward the message to network device 580. Similarly, when gateway 502 receives a subscription request from network device 580 to receive API messages published by a specific system controller, such as system controller 250a, the gateway may forward the request to the network server via API converter 504 for conversion, if necessary. Assuming the network server receives API messages published by system controller 250a at connection 334, the network server can forward those API messages to API converter 504. API converter 504 can be configured to subsequently convert the API messages into third-party API messages and forward the third-party API messages to gateway 502, which can then forward the messages to network device 580.
[0105] According to one example, system 500 may include multiple API converters 504, each configured to translate messages between an API used by a system controller and a third-party API used by a network device, and each API converter has a corresponding connection 510 to gateway 502. When network device 580 needs to communicate with and / or receive messages from a specific system controller 250a or 250b, gateway 504 may use the "available" API converter 504 for said communication. In other words, a given API converter 504 may only support communication with one system controller 250a and 250b at any given time. According to one example, API converters 504 may exist statically (i.e., a defined number exist that are "running" or executing at any given time), and gateway 502 may use available / free converters as needed. According to another example, API converters may be formed by gateway 502 as needed. According to this example, gateway 502 and API converters 504 may be dedicated to a specific third-party API. As discussed below, additional instances of Gateway 502 and API Converter 504 can be used to support additional third-party APIs.
[0106] Assume system 500 includes multiple API converters 504, such as Figure 5 As further illustrated, each API converter may have a corresponding communication connection 512 with web server 340, and more specifically, web service 342. This connection may be based on TCP / IP or UDP / IP, but other connections may also be used. Web server 340 / web service 342 may support HTTP / HTTPS-based interfaces over this connection using standard methods discussed herein.
[0107] The following describes an example operation of system 500. To transmit a specific command or request, for example, to a specific system controller 250, such as system controller 250a, network device 580 can transmit a third-party API message to gateway 502 via communication connection 508. For example, the network device can use a standard POST command to transmit the message. This third-party API message may include the MAC address of system controller 250a (i.e., "A1:B1:C1:D1:E1:F1") (but a unique system controller ID value may also be used, for example). Upon receiving the message, gateway 502 can forward the third-party API message (and the MAC address) to the corresponding API converter 504 via connection 510. Upon receiving the message, API converter 504 can convert the third-party API message into an API message. Thereafter, for example, the operational flow can be similar regarding... Figure 4The discussion proceeds as follows. API converter 504 can then publish API messages to network service 342 via corresponding connection 512, and specifically, can publish messages to the MAC address of system controller 250a (i.e., "A1:B1:C1:D1:E1:F1"). Note that since the API converter has published the API message to the MAC address, network service 342 can use subscription database 346 to translate the MAC address into a "request" topic associated with the MAC address (here, " / u / 1202 / d / ABC123 / request"). Subsequently, the network service can forward the API message and the " / u / 1202 / d / ABC123 / request" topic to MQTT client 472. MQTT client 472 can then publish the API message to message broker 370 via connection 474 using the topic " / u / 1201 / d / ABC123 / request". Additionally, MQTT client 472 can also use message broker 370 to subscribe to the “response” topic associated with the MAC address of controller 250a (i.e., “ / u / 1202 / d / ABC123 / response”) via connection 474. By subscribing to the “response” topic of system controller 250a, MQTT client 472 can receive any responses to API messages from system controller 250a.
[0108] Therefore, when process 476 of message broker 370 receives an API message from MQTT client 472, the message broker can forward the API message to process 272a, which in turn forwards it to system controller 250a (as described above, controller 250a has subscribed to the topic " / u / 1202 / d / ABC123 / request"). For example, when system controller 250a processes the API message, it can generate a response API message, which it can publish to message broker 370 using the topic " / u / 1202 / d / ABC123 / response" as described for systems 200, 300, and 400. Because MQTT client 472 has subscribed to the topic " / u / 1202 / d / ABC123 / response", message broker 370 can forward this response API message from process 272a to process 476, which can then forward the response API message to MQTT client 472 via connection 474. Upon receiving the response API message, MQTT client 472 can unsubscribe from the topic " / u / 1202 / d / ABC123 / response" and forward the response API message to network service 342. Network service 342 can then translate the topic of the response API message from " / u / 1202 / d / ABC123 / response" back to the MAC address of system controller 250a and transmit the response API message to API converter 504 via connection 512.
[0109] After receiving an API response message from network service 342, API converter 504 can convert the API message into a third-party API message (e.g., a response message) and forward the third-party API message to gateway 502 via connection 510. Gateway 502 can then forward the third-party API message to network device 580. Other variations are also possible.
[0110] Similarly, for example, for network device 580 to subscribe to receive API messages published by a system controller, such as system controller 250a, network device 580 can communicate with gateway 502 via communication connection 508 to subscribe to the MAC address of system controller 250a. After receiving the subscription request, gateway 502 can forward the request to a corresponding API converter 504 via corresponding connection 510, which can then forward the request to network service 342 via corresponding connection 512, thereby translating the request as needed. Alternatively, gateway 502 can forward the subscription request directly to the network service. In any case, for example, the operational process can then be as described regarding Figure 3 The discussion proceeds similarly. When network service 342 receives API messages published by system controller 250a from data aggregator 310 via connection 334, the network service can determine that a network device, such as network device 580, has subscribed to receive these API messages, as discussed herein. Network service 342 can then forward these API messages (e.g., along with their associated topics and / or MAC addresses) to the corresponding API converter 504 via the appropriate connection 510. Alternatively, network service 342 can forward these API messages to worker service 344 (e.g., via message queue 348), which in turn can forward the API messages (e.g., along with their associated topics and / or MAC addresses) to the corresponding API converter 504 via the appropriate connection 510. Other variations are also possible. After receiving API messages from network service 342, API converter 504 can convert the API messages into third-party API messages and forward the third-party API messages to gateway 502 via the appropriate connection 510. Gateway 502 can then forward the third-party API messages to network device 580. When transmitting third-party API messages to a network device, the message may include the subject associated with the API message and / or the MAC address of the corresponding system controller 250a. Other variations are also possible.
[0111] As indicated above, according to Figure 5In the example shown, gateway 502 and API converter 504 can be dedicated to a specific third-party API. According to another aspect of system 500, the system can support multiple different third-party APIs. Here, system 500 may include multiple instances / pairs of gateway 502 and API converter 504, where each gateway / API converter pair supports a corresponding third-party API. Depending on which API network device 580 uses, the device can communicate with the corresponding gateway (e.g., each gateway may have a corresponding address / URL with which the network device communicates).
[0112] In a specific instance, one or more of gateway 502 and API converter 502 may be provided by Amazon Web Services, wherein gateway 502 may be an Amazon API Gateway, and wherein each corresponding instance of the API converter may be a corresponding Lambda function configured to perform API transformations as discussed herein and to communicate with web server 340 as discussed herein. Here, the Amazon API Gateway may expose endpoints to network device 580 and may assign Lambda functions configured as described herein to the corresponding gateway endpoints.
[0113] For example, referring now to another aspect of systems 300, 400, and 500, as discussed herein, network server 340 may use, for example, the MAC addresses of system controllers 250a and 250b as / used as topics or channels to which network devices 380 and 580 may subscribe and / or publish messages. Subscription database 346 may include the MAC addresses of system controllers and may associate these addresses with one or more topics used by system controllers 250a and 250b, as illustrated by label 350. Again, this is just one example.
[0114] According to another example, authorization / access tokens can also be associated with corresponding system controllers 250a and 250b, and these tokens are subsequently associated with one or more topics used by the system controllers, where systems 300, 400, and 500 use the tokens in a manner similar to how MAC addresses can be used as described herein. For example, for security purposes, in order for network device 380 or 580 (i.e., a third party) to communicate with network server 340 or gateway 502 to access user environment 202a or 202b / load control system 210a or 210b, the network device may need to include, for example, an authorization / access token in an HTTP message, which can be used by network server 340 and / or gateway 502 to ensure that the network device is allowed access to user environment 202a or 202b / load control system 210a or 210b. Users of the user environment / load control system (e.g., homeowners) can obtain such tokens using, for example, an OAuth-based service (e.g., OAuth 2.0). Such services can be provided separately from systems 300, 400, and 500. During the process of a user obtaining such a token, the token may be stored in, for example, a subscription database 346, and may also be provided to a third party and used by the third party and web server 340 and / or gateway 502 for authentication / authorization purposes.
[0115] In this respect, authorization tokens can be considered as associated with a user. Depending on aspects of systems 300, 400, and 500, these tokens can also be associated with system controllers. For example, suppose a user / host in user environment 202a obtains token "XYZ123" through an OAuth-based service, and suppose a user / host in user environment 202b obtains token "XYZ456" through an OAuth-based service. Besides using these tokens for security purposes, these tokens can, for example, be stored in a subscription database 346 (or alternatively, in another database, such as an authorization database, where database 346 has links to the tokens stored in the authorization database), and are associated with the respective system controllers 250a and 250b, and thus with one or more topics used by the system controllers, such as in... Figure 5 As shown in label 350.
[0116] Such as about Figure 3As discussed in system 300, in order for network device 380 to receive API messages published by system controller 250a, the network device may, for example, subscribe to a MAC address such as “A1:B1:C1:D1:E1:F1” as discussed herein. Regarding authorization tokens, when network device 380 sends an HTTP message to network server 340 to subscribe to receiving API messages from system controller 250a, network server 340 may treat / use the authorization token (i.e., “XYZ123”) within the HTTP message as / as a request to subscribe to the authorization token, wherein system 300 now uses the token in a manner similar to how the system uses MAC addresses in order to determine whether the API message published by system controller 250a should be forwarded to the network device.
[0117] Similarly, such as regarding Figure 4 As discussed in system 400, in order for network device 380 to transmit API messages to system controller 250a, the network device may, for example, publish the message to the MAC address of the system controller. Regarding authorization tokens, when the network device transmits an HTTP message to the network server to publish the API message to system controller 250a, the network server 340 may treat / use the authorization token (i.e., “XYZ123”) within the HTTP message as / as a request to publish the API message to the authorization token, wherein system 400 now uses the token in a manner similar to how the system uses MAC addresses in order to communicate the API message with system controller 250a.
[0118] Similarly, such as regarding Figure 5As discussed in system 500, in order for network device 580 to transmit third-party API messages to system controller 250a, the network device may, for example, transmit the MAC address of the system controller to gateway 502. Regarding authorization tokens, when network device 580 transmits an HTTP message (including the third-party API message) to the gateway, the gateway may forward the authorization token (i.e., “XYZ123”) from the HTTP message to API converter 504, which may convert the third-party API message into an API message. When API converter 504 transmits the HTTP message to network server 340 to publish the API message to system controller 250a, the API converter may include a token containing the HTTP message (e.g., for authorization purposes). Network server 340 may then treat / use the authorization token (i.e., “XYZ123”) within the HTTP message as / as a request to publish the API message to authorization tokens, where system 500 now uses the token in a manner similar to how the system uses MAC addresses to communicate the API message with system controller 250a. The authorization token can also be used in system 500 for network device 580 in a similar manner to subscribe to receive API messages published by the system controller. Similarly, other instance process flows are also possible.
[0119] Generally, it should be recognized that the functions and operations described herein as those of message broker 370, data aggregator 310, and web server 340 can each be executed on different computing devices, the same computing device, or a combination thereof. One or more of these modules can also be cloud-based systems. Similarly, it should be recognized that the functions and operations described herein as being performed by message broker 370, data aggregator 310, or web server 340 can be performed by other modules. For example, web server 340 can provide filter 316 instead of data aggregator 310. Furthermore, although the functions and operations are described herein as being performed by message broker 370, data aggregator 310, and web server 340, they can also be performed by additional modules. For example, network service 342 and worker service 344 can be distributed across multiple computing devices. Subscription database 346 can be a database management system separate from network service 340, etc. Other variations are also possible.
[0120] Now for reference Figure 6A -V, now describes instance control application 1103 that can be executed at least partially on network device 680. Figure 10Network device 680 may be similar to any of network devices 144, 280a-280b, 380, and 580 as described herein, and may be, for example, a personal computer (PC), laptop, tablet, smartphone, or equivalent device, but may also be another type of computing device. The control application may be a graphical user interface (GUI) based application that provides a GUI-based interface / GUI-based "window" to a user via network device 680, and allows the user of the network device to interact with control devices within the user environment (e.g., control device 220a of user environment 202a), control the control devices, and / or configure the control devices. For purposes of description only, the load control system 210a of user environment 202a and related... Figures 2 to 5 The communication system described herein will be used as an example load control system and communication system to describe the control application. However, the features and functions of the control application 1103 described herein can be applied to other types of control devices, load control systems, and communication systems. As an example, the user environment 202a can be a residence or house, and the user of the network device 680 can be the address of the house. However, the example control application can also be applied to other types of user environments, such as buildings, hotels, etc.
[0121] Figure 10An example block diagram of network device 680 is shown (e.g., this diagram can also be applied to any of network devices 144, 280a-280b, 380, and 580). Network device 680 may include one or more general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), microprocessors, microcontrollers, integrated circuits, programmable logic devices (PLDs), application-specific integrated circuits (ASICs), etc., and / or may also include other processing elements, such as one or more graphics processors (collectively referred to below as processor 1102). In addition to other software applications, such as operating systems, database management systems, etc., processor 1102 can control the functions of the network device and can execute control application 1103 to provide the features and functions as described herein. Processor 1102 can also perform signal decoding, data processing, power control, input / output processing, and any other functions that enable network device 680 to perform as described herein. Network device 680 may further include one or more memory modules / devices 1104 (including volatile and non-volatile memory modules / devices), which may be non-removable and / or removable. Memory modules / devices 1104 may be communicatively coupled to processor 1102. Non-removable memory modules / devices 1104 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of non-removable memory storage device. Removable memory modules / devices 1104 may include a user identity module (SIM) card, memory stick, memory card, or any other type of removable memory. One or more memory modules / devices 1104 may store control application 1103 and may also provide execution space when the processor executes the control application. Network device 680 may further include a visual display / terminal 1106 communicatively coupled to processor 1102. The visual display 1106 may, together with processor 1102, display information to a user via one or more GUI-based interfaces / GUI-based “windows” as described herein. Display screen 1106 and processor 1102 can communicate bidirectionally because display screen 1106 may include a touch-sensitive visual screen module configured to receive information from the user and provide this information to processor 1102. Network device 680 may also include one or more input / output (I / O) devices 1112 (e.g., keyboard, touch pad, mouse, trackball, audio speaker, audio receiver, etc.) communicatively coupled to processor 1102. For example, the I / O devices may allow the user to interact with control application 1103. Network device 680 may also include one or more transceiver / communication circuits (collectively referred to as communication circuitry 1108) for transmitting (transmitting and / or receiving) over wired and / or wireless communication networks.Communication circuitry 1108 may include an RF transceiver or other circuitry configured to perform wireless communication via an antenna. Communication circuitry 1108 may communicate with processor 1102 to transmit and / or receive information. Each module within network device 680 may be powered by power supply 1110. For example, power supply 1110 may include an AC power supply and / or a DC power supply. Power supply 1110 may generate a power supply voltage V. CC It is used to power the modules within the network device 680.
[0122] In addition to GUI-based software modules that provide, for example, the graphical features and visual images described herein, the control application 1103 may also include a logic engine for providing features of the GUI and, generally, features of the application as described herein. The GUI-based software modules and / or logic engine may be one or more software-based modules, including, for example, instructions stored on and / or executed from one or more physical memory devices / modules of the aforementioned network device. Besides / as an alternative to software-based modules, the features of the control application may also be provided by firmware and / or hardware. Similarly, network device 680 is an example, and the control application may execute on other types of computing devices.
[0123] As shown, network device 680 can be similar to any of network devices 144, 280a-280b, 380, and 580 as described herein. Therefore, the control application can communicate with the system controller 250a of user environment 202a via a network local to the user environment (e.g., a Wi-Fi network), similar to device 144 described herein; can communicate with the system controller 250a using message-based protocols (e.g., MQTT) and message brokers (e.g., message broker 270), similar to network devices 280a-280b described herein; and / or can communicate with the system controller 250a using an HTTP-based interface, similar to network devices 380 and / or 580 described herein. However, it should be recognized that control application 1103 / network device 680 can communicate with the system controller 250a using other communication systems and / or protocols, etc. Additionally, control application 1103 is described herein as a standalone application, for example, executing on a network device and transmitting messages with the system controller 250a. In other words, the logic controlling the application and the resulting graphics associated with the application are described herein as being executed from a network device. However, the features and / or graphics controlling the application can be implemented in other ways, such as in a network-hosted application, where the network device uses a local application (e.g., a web browser or other application) to interface with the network-hosted application to provide the features and functionality as described herein.
[0124] Typically, while user environment 202a may include control device 220a, with which control application / network device 680 can interact, control, and / or configure control device via system controller 250a, the user environment may also include other types of control devices, such as Wi-Fi and / or HomeKit enabled control devices (e.g., devices configured to communicate via wireless and / or wired networks). For purposes of description only, such other control devices (i.e., control devices with which control application / network device 680 does not communicate via system controller) will be referred to herein as Wi-Fi and / or HomeKit enabled control devices. However, it should be understood that the features described herein are not limited to control devices that are only Wi-Fi and / or HomeKit enabled. Examples of such other control devices may include lighting control devices / light bulbs, thermostats, fans, etc. Network device 680 and these Wi-Fi-enabled control devices can be configured, for example, to communicate directly with each other without having to communicate through system controller 250a (e.g., if the network device is also HomeKit-enabled), and / or to communicate via one or more cloud-based servers, again without having to communicate through system controller 250a. According to one aspect of the control application 1103 described herein, assuming the network device is configured to communicate with such Wi-Fi-enabled control devices (e.g., via HomeKit), the control application can be configured to interact with, control, and / or configure these devices in addition to control device 220a. In doing so, the control application can combine information obtained from, for example, such Wi-Fi-enabled devices, with information obtained on control device 220a controlled by system controller 250a within the graphical interface described herein. The control application can also provide an interface that allows the user to control both, for example, the Wi-Fi-enabled control device and the control device 220a controlled by the system controller. For ease of description, the control application will be described herein as interacting with control device 220a of load control system 210a. However, similar functionality as described herein can also be applied to Wi-Fi-enabled devices that are not controlled via system controller 250a and to which network devices can communicate directly and / or indirectly. Users may not easily understand which types of devices the control application interacts with. It should be recognized that the control application described herein can alternatively control only, for example, Wi-Fi-enabled devices, with network devices configured to directly and / or indirectly control / interact with said Wi-Fi-enabled devices. Similarly, it should be further recognized that although this document describes load control system 210a and, for example, reference... Figures 2 to 5The control application 1103 is described in the context of the communication system described, but the features and functions of the control application can be applied to other types of control devices, load control systems, and communication systems, such as those including systems with Wi-Fi enabled and / or HomeKit enabled.
[0125] As an example, network device 680 can display an icon associated with a control application to a user via a visual display. The network device can detect the user's selection of the icon (e.g., detecting a touch to use the icon), and in response, can launch (also referred to herein as initiating, running, executing, activating, and / or invoking) the control application (it should be appreciated that the control application can be launched in other ways, including when the network device is configured to automatically launch the application after a reset and / or power-on). In response to launching or initiating, the control application (e.g., in addition to performing a security / authentication process) can transmit one or more messages to system controller 250a, such as obtaining / requesting / querying various information, such as the status / condition and / or configuration information of the load control system 210a, and using this information to initially generate a graphical user interface, for example... Figure 6AThe graphical user interface 610 is displayed to the user via the display screen of the network device 680. Also upon startup, for example, the control application may communicate with a Wi-Fi enabled device, such as a network device configured to communicate with such a Wi-Fi enabled device. Subsequently, depending on the information the control application may need to display to the user and / or is generating by the system controller, the control application may continue to request and / or receive various information from the system controller 250a at various times. (Similarly, the control application may also communicate with Wi-Fi enabled devices in a similar manner.) After receiving an information request (e.g., a request for status and configuration information) from the control application, the system controller 250a may respond by communicating with the control device 210a and / or the database 254, for example, by determining and providing the requested information and responding to the control application with one or more response messages. In addition to determining the status and configuration of the load control system, the control application may, for example, allow the user to transmit messages to the system controller 250a to modify, edit, or change the configuration and / or status of the load control system 250a, as further described herein. Additionally, system controller 250a can asynchronously provide status and configuration information to the control application (e.g., providing indications of status / state changes of the control device without requiring the control application to query such changes). The control application can use this information to update various graphical user interfaces displayed to the user via network device 680. (Similarly, Wi-Fi-enabled devices and control applications / network devices can interact in a similar manner.) Likewise, control application / network device 680 and system controller 250a can use the information referenced above. Figures 2 to 5 The communication mechanism under discussion.
[0126] Before proceeding to the various graphical user interfaces that the control application can provide to the user, we will first discuss a description of the instance types of information that the control application can request / receive from the system controller 250a to, for example, generate the interface. It should be recognized that these are instances and other types of information can be provided. In addition to receiving this information from the system controller, the control application can also modify this information at the system controller, as described below.
[0127] The control application can request / obtain information related to the configuration and current status / condition of the load control system 210a from the system controller 250a. Such information provided by the system controller 250a may include specific control devices that are part of the load control system 210a, including identifiers indicating the type of control device. Specific control device types may include: one or more lighting control devices (also referred to herein as lighting devices) that each directly controls one or more corresponding electric lighting loads / lamp; one or more temperature control devices (e.g., also referred to herein as thermostat devices) that directly control one or more corresponding HVAC systems; one or more ceiling fan devices (also referred to herein as fan devices) that each directly controls one or more corresponding fans (e.g., on, off, fan speed); one or more audio control devices (e.g., speaker systems); and one or more blackout curtain devices that each directly controls the position or level of one or more corresponding blackouts (it should be recognized that although blackout devices and blackouts are discussed herein as motorized curtains and blinds, other types of motorized curtains and blinds are also possible, such as pleated blinds, horizontal blinds, Venetian blinds, etc.). Control devices may also include one or more buttons, such as wall-mounted buttons, desktop buttons, and / or remote / handheld buttons and devices. As an example, a given button may include one or more actuators, such as a push button (but other types of actuators are also possible), and may be configured to control one or more control devices / electrical loads (e.g., lighting control devices / lighting loads, HVAC systems, shading devices, fans, and / or speakers, etc.). Typically, a button may include different types of actuators, such as on / off actuators, lifting actuators for lights or shading devices, fan speed actuators, scene actuators, etc. Scene actuators can set one or more control devices / electrical loads controlled by the button to a preset configuration.
[0128] The control device may also include one or more occupancy / idle sensors and / or one or more idle-only sensors. As an example, an occupancy / idle sensor can signal other control devices to detect occupancy events / statuses and idle events / conditions (e.g., after an occupancy event is detected). The sensor can signal these events by generating an occupancy signal / message when it detects an occupancy event, by generating a periodic occupancy signal / message when it detects continuous occupancy events, and / or by generating an idle signal / message when it detects an idle event (e.g., after an occupancy event is detected). As another example, the sensor can signal idle events by ceasing to generate periodic occupancy signals / messages. An idle-only sensor can signal other control devices to detect idle events / conditions (e.g., after an occupancy event is detected). The idle-only sensor can signal these events by generating an idle signal / message when it detects an idle event (e.g., after an occupancy event is detected). In this example, the sensor may still generate a signal / message when it detects an occupancy event, but the control device may not respond to such a signal. As another example, an idle-only sensor can signal an idle event by ceasing to generate periodic occupancy signals / messages. It should be recognized that these are examples, and the sensor may operate in other ways based on detected occupancy / idle events. It should also be recognized that when a sensor detects an occupancy and / or idle event, it can transmit these events in various ways, such as by transmitting signals or messages. Such signals can be transmitted via wireless communication, wired communication, optical communication, etc. Other examples are also possible. For ease of description, occupancy / idle sensors and idle-only sensors are collectively referred to herein as occupancy sensors, and the sensor generates a signal upon detecting an occupancy and / or idle event.
[0129] The load control system 210a can be configured such that one or more control devices 220a can respond to signals from a given occupancy sensor (e.g., respond to occupancy and / or vacancy events detected by the sensor). For example, the load control system 210a can be configured such that one or more lighting control devices can respond to occupancy and vacancy signals from a given occupancy sensor. For example, in response to an occupancy signal from an occupancy sensor, a given lighting control device that is off (i.e., its corresponding lighting load is off) can turn on its corresponding lighting load, and specifically, can set the lighting load to a defined lighting / dimming level. In response to a vacancy signal, a given lighting control device can turn off its corresponding lighting load when it is on, or can reduce its lighting level to a defined lighting / dimming level. As another example, the load control system 210a can be configured such that one or more lighting control devices can respond only to occupancy signals from a given occupancy sensor. As another example, the load control system 210a can be configured such that one or more lighting control devices can respond only to vacancy signals from a given occupancy sensor. For example, in response to an occupancy signal from an occupancy sensor, a given lighting control device can ignore the signal. In response to an idle signal, a given lighting control device may shut off its corresponding lighting load or reduce its lighting level to a defined lighting / dimming level when it is turned on. How a given lighting control device responds to an occupancy and / or idle signal from a given occupancy sensor may be stored as part of a signal at the sensor and transmitted to the lighting control device, may be stored at the lighting control device itself, and / or may be stored at a system controller 250a, which may, for example, receive occupancy and idle signals and subsequently control the lighting control device. It should be recognized that a given lighting control device may respond to signals from more than one occupancy sensor. Similarly, multiple lighting control devices may respond to signals from the same occupancy sensor and may each be configured to respond to the signals in different ways. It should also be recognized that the load control system 210a may be configured such that other control devices (e.g., fan devices, shading devices, thermostat devices, and audio devices, etc.) may respond to occupancy and / or idle signals from the occupancy sensor. Typically, the occupancy sensor may be a separate device, i.e., a device separate from the control device (e.g., the lighting control device) that can respond to the signals generated by the sensor. As another example, the occupancy sensor can be integrated with another control device, such as a lighting control device. The control device with the integrated sensor can respond to the signal generated by the sensor, and / or a control device separate from the control device with the integrated sensor can respond to the signal generated by the sensor. It should be recognized that other examples are also possible. It should be recognized that the load control system 210a can include other types of control devices.
[0130] The information provided by system controller 250a may also include location indicators for each control device, which may indicate the location of the device within user environment 202a and / or the location of the electrical load controlled by the device. While other mechanisms may be used, this indicator may take the form of a location name (e.g., a text string) and / or an indicator that can be converted into a location name (e.g., a text string). For example, assuming the user environment is a house, locations may include standard locations such as “kitchen,” “living room,” “family room,” “dining room,” “master bedroom,” “bedroom,” “master bathroom,” “bathroom,” “basement,” “front porch,” etc. Locations may also include sub-locations within a room, such as “basement-rest area,” “basement-game area,” “basement-work area,” “basement-storage area,” etc. Locations may also include user-defined / custom locations such as “Mary’s bedroom,” “John’s bedroom,” etc. When the system is installed within user environment 202a, the locations of the control devices may be programmed by the user into load control system 210a (and stored, for example, in database 254). It should be recognized that these are examples.
[0131] For lighting control devices, the information provided by system controller 250a may also include a type indicator that indicates the type of lighting load (also referred to herein as a lamp) controlled by the control device. The type of lighting load may include, for example, the function / purpose of the lighting load within its defined location, and / or an indication / suggestion of a specific location for the lighting load within its defined location (e.g., ceiling lights versus floor lights). Although other mechanisms may be used, the type indicator may take the form of a name / function (e.g., a text string) and / or an indicator that can be converted into a name / function (e.g., a text string). As an example, assuming user environment 202a is a house, standard types may include ceiling lights or ceiling lights, chandeliers, pendant lights, table lamps, floor lamps, wall lights, sink lights (e.g., for kitchens or bathrooms), island lights (e.g., for kitchens), closet lights, etc. Types may also include user-defined / custom types. When the system is installed within user environment 202a, the type of lighting load may be programmed by the user into the load control system 210a (and, for example, stored in database 254). It should be recognized that these are examples. Types can also be applied to other control devices, such as fans, light shields, and buttons. Similarly, type indicators can provide indications of a specific function and / or location within a defined area of the device. Other example types may include "left light shield," "right light shield," "center light shield," "wall button," "desktop button," etc.
[0132] The information provided by system controller 250a may also include icon indications, which will be used in conjunction with an application (e.g., a control application) to graphically represent the control device on a graphical interface. The types of icons associated with the device may be programmed by the user or automatically into the load control system 210a when the system is installed within the user environment 202a (and stored, for example, in database 254).
[0133] The information provided by system controller 250a may also include the current status / state and / or configuration of one or more control devices. For example, for a lighting control device, status information may include whether the corresponding lighting load is on or off, and if on, whether the lighting load is dimmed and may also include the dimming level. For a shading device, status information may include whether the corresponding shading is open / closed, closed / closed, partially open / closed, and if partially open / closed, may include the actual level of the shading. For a thermostat device and the corresponding HVAC system, status information may include the system's setpoint / target temperature, the current room temperature measured by the thermostat device, the current mode setting (e.g., heating, cooling, auto, off), the current fan setting (e.g., on, auto), and schedule information (e.g., on and off, assuming the thermostat device is programmable to have a schedule). For a ceiling fan device, status information may include whether the corresponding fan is on or off, and if on, may include the fan speed. For audio control devices (e.g., speaker systems), status information may include, for example, whether the device is on / playing music or off and / or muted. For button devices, such as wall-mounted, desktop, and / or handheld / remote buttons, status information may include which actuator of the device was last executed (i.e., currently active), and if the button has one or more actuators corresponding to a scene, it may include the configuration of each scene (e.g., which controls are part of the scene, and the settings of these controls for the scene, such as light level or fan speed). The control application may allow the user to modify these scenes and create new scenes via a network device. For occupancy sensors, status information may include, for example, whether the sensor has detected an occupancy event / condition and / or is in an occupancy state, whether a continuous occupancy event / condition and / or is in a continuous occupancy state, and / or whether an vacancy condition and / or is in an vacancy state. Again, these are examples, and other information is possible.
[0134] As another example, system controller 250a can maintain information relating to one or more pre-programmed scenarios that can be executed by a user from an application such as control application 1103. A scenario can be, for example, a specific setting for one or more lights, shading objects, etc. System controller 250a can maintain corresponding scenario configuration information in database 254. The control application can obtain information relating to these pre-programmed scenarios from the system controller and, as further described below, allow the user to select a given scenario via a network device, thereby generating control application instructions. The system controller then configures control device 220a according to the selected scenario (e.g., setting one or more light levels, fan speeds, shading levels, etc.). Also as described below, the control application can allow the user to modify the pre-programmed scenarios maintained by the system controller and create and store new scenarios on the system controller that can subsequently be selected by the user.
[0135] As another example, system controller 250a can maintain various clock schedules, where the schedules can be specific settings for, for example, one or more control devices (e.g., lights, shading objects, etc.), and the system controller automatically configures said settings based on the schedules. System controller 250a can maintain the corresponding clock schedules and the status of these schedules in database 254, such as whether a given schedule is active, inactive, or disabled. Control applications can obtain control information related to these clock schedules from the system, and, as further described below, allow users to modify these schedules and create new schedules via network devices.
[0136] Turn now Figure 6AA graphical user interface 610 is shown, which can be initially displayed to the user via a network device 680 by the control application when the application is initially launched (e.g., by the user selecting and launching the application at the network device). Similarly, the information displayed in the user interface 610 can be based on information obtained by the control application from the system controller 250a when the application is launched. The user interface 610 may include three sections (also referred to herein as panes, areas, or spaces): a status section (or pane) 620, a menu selection section (also referred to herein as a menu selection pane, tab section, or tab pane) 640, and an information section (or pane) 660. As further described below, the status section 620 can provide the user with the status / state of the control device 220a in the load control system 210a. The menu selection section 640 can provide the user with optional tabs (three tabs are shown here, including a "Device" tab 642, a "Scenario" tab 644, and a "Schedule" tab 646, but the section may include fewer or additional tabs, including three tabs in a different order than shown). For example, segment 640 may be scrollable left and right to display additional labels. The control application can change and / or display information in segment 660 depending on which label is selected; therefore, segment 660 can depend on the selected label. Typically, information segment 660 can provide the user with various status information and controls for controlling and / or configuring the load control system 210a. Figure 6A In this example, device label 642 is active (as shown by underline 643, but other methods, such as reverse highlighting, can also be used to indicate which label is currently active). Here, section 660 shows the information corresponding to device label 642. After the control application starts, the control application can default the user interface 610 to device label 642 being active, but one of the other labels can also be the default active label.
[0137] As indicated, starting with section 620, this section may display the status / state of one or more control devices 220a within the load control system 210a. In this example, the control application displays three icons, each indicating different status information. Icon 622 may be referred to herein as the lighting device icon, which indicates to the user the number of lighting control devices within the load control system that have the corresponding lighting load currently on. Icon 624 may be referred to herein as the shading device icon, which indicates to the user the number of shading devices within the load control system that have the corresponding shading currently open / closed (where open / closed can be any shading state different from fully closed / closed). Icon 626 may be referred to herein as the thermostat device icon, which indicates to the user the current temperature in the user environment 202a. It should be recognized that fewer and / or additional icons may be displayed by the control application in section 620 to convey additional and / or other information to the user. For example, Figure 6B Another example of a graphical user interface 601 is shown, which includes icons 628, referred to herein as audio device icons, which can indicate to the user the status of audio devices within a load control system, such as whether any audio devices are currently turned on / playing music and / or the number of devices currently turned on / playing music. The control application can be configured such that section 620 can be "scrolled" (e.g., from left to right or up / down) by the user to display additional icons. As another example, section 620 can be configured to display multiple rows of icons to the user at once. As another example, section 620 may include, for example, Figure 6L The icon shown herein, referred to as fan icon 776, indicates to the user the status of fan units within the load control system, such as the number of fans currently on. Section 620 can also be configured by the user of the application to display only certain icons and their corresponding status information, while omitting others. According to another example, if no status is reported for a given load control unit (e.g., all lighting is off), the control application may not display the corresponding icon at all. Other examples are also possible. Reference will now be made in more detail to representative icons that the control application may display in section 620.
[0138] As indicated, starting with icon 622, the number of lighting control devices within the load control system 210a that have a corresponding lighting load currently on can be indicated to the user using lighting device icons. The control application can determine this number based on information obtained from the system controller 250a. A given lighting control device can control more than one lighting load and can control these loads simultaneously (or these loads can be individually controlled to different states). According to one example, the control application can consider a given lighting control device and its corresponding lighting load as a single device. In this example, as long as one lighting load controlled by the lighting control device is on, the control application can count this as one (1) relative to the number associated with icon 622, regardless of the number of controlled loads actually controlled by the device (and possibly actually on). However, it should be recognized that the number associated with icon 622 can represent the actual number of lighting loads controlled by each lighting control device. Here, the control application can view each lighting load controlled by a given lighting control device individually. In this example, the number associated with icon 622 can represent each lighting load. Therefore, if two lighting loads controlled by the lighting control device are in the on state, the control application can count this as two relative to icon 622 (2). For descriptive purposes, this document describes the control application from the perspective of the lighting control device, where the lighting control device and its corresponding lighting load are considered as a single unit. Figure 6A In this example, the control application determines, based on information received from system controller 250a, that eight lighting control devices are currently turning on the load (where "on" can include the lighting load being in a dimming state and / or a fully on state). The control application can, as shown in... Figure 6AThe number “8” associated with icon 622 indicates this determination to the user (however, it should be recognized that other variations are possible, such as displaying the word “eight” or a symbol representing 8, such as 8 dots, etc.). As an example, the control application could actually perform a count based on information received from the system controller to determine the number 8 (e.g., searching a list of lighting controls and determining how many are on), or the system controller could perform a count and report the resulting value to the control application. Other variations are also possible. In addition to displaying the number of lighting controls determined to be currently on (i.e., turning on at least one of the corresponding lighting loads of the lighting controls), the control application could also proactively update the number displayed by icon 622 (increase / decrease), for example, based on the system controller 250a actively monitoring the on / off status of lighting controls in the user's environment (e.g., due to the user turning lights on and off in the environment) and reporting this information asynchronously (e.g., “in real time” or when a status change event occurs) to the control application. As an alternative, the control application can periodically request the status of lighting control devices and / or lighting loads from the system controller 250a after startup, and update the number displayed by icon 622 based on the response from the system controller 250a. In this way, icon 622 allows the user to quickly and easily determine from network device 680 whether any lighting loads are on in the user's environment. If it is determined that no lighting loads are currently on, the control application can display the value "0" using icon 622, can display no value without using the icon, or can not display the icon at all (thus indicating that no lighting control devices are on, etc.). Other variations are also possible. For example, instead of displaying the number using icon 622, the control application can display the icon when any lighting load is on, and not display the icon when all lighting loads are off. As yet another example, icon 622 can indicate the number of lighting control devices with corresponding lighting loads that are off.
[0139] Icon 622 can also be selected by the user. After detecting / determining that the user has selected icon 622, the control application can display the following to the user via network device 680: Figure 6CThe graphical user interface 702 is shown. Interface 702 may continue to display icon 622 and the number of lighting control devices with at least one lighting load determined to be currently on. Interface 702 may also include a "Turn off all lights" icon 704 selectable by the user (but other text and / or icons may be used). Interface 702 may also include a corresponding icon 706 for each lighting control device with a currently on lighting load (again, according to this example, the control application may be configured to treat the lighting control device and its corresponding lighting load as a unit, representing the unit uniformly as a single icon. Alternatively, each lighting load controlled by the lighting control device may be represented by an icon in interface 702 or a combination thereof). Each of these icons may also be selectable by the user. In this example, as shown by icon 622, eight icons 706 are shown in conjunction with the value "8". The control application can use location indicators associated with each lighting control to display an icon indicating the location of the corresponding device / lighting load in the user's environment (in this example, text information such as "kitchen," "living room," "front porch," and "master bedroom" is used, but other mechanisms, such as separating icons by location, could also be used). Figure 6A Section 660 is similar, but only displays icons for currently active devices. The control application can also use type indicators associated with each lighting control device to combine each icon with further indications of the device / lighting load's location and / or function (in this example, text information such as "ceiling light," "chandelier," "sink light," "wall light," and "table lamp" is used, but other mechanisms are possible). Figure 6C As further illustrated, different icons can be used for various lighting control devices / lighting loads (example icons are used here to represent chandeliers, table lamps, wall lamps, and light bulbs, and other icons are also possible). As indicated, the system controller can provide an indication of the type of icon the control application should use. As another example, the control application can use location indicators and / or type indicators associated with each lighting control device, for example, to determine which icon to use. Typically, the use of textual information and custom icons in the control application allows users to more easily identify the actual lighting control device / lamp in the user's environment that the icon refers to.
[0140] According to another aspect of interface 702, in a manner similar to how a control application actively updates the number displayed by icon 622 based on, for example, the system controller 250a actively monitoring the status of lighting control devices in the user environment, the control application can actively update the icon 706 displayed to the user when a lighting control device in the user environment changes from on to off and from off to on (i.e., when the lighting load controlled by the device changes state). In other words, when a lighting control device turns on a corresponding lighting load (e.g., at least one of the loads), the control application can receive an indication of this change from the system controller 250a (e.g., automatically or in response to a query from the control application) and display additional icons 706 associated with the lighting control device to the user in interface 702 (in addition to increasing the number associated with icon 622). Similarly, when a lighting control device turns off all corresponding lighting loads, the control application can receive an indication of this change from the system controller 250a and remove icons 706 associated with the lighting control device from interface 702 (in addition to decreasing the number associated with icon 622). As another example, instead of removing the icon from interface 702, the control application can change the icon's appearance (e.g., change its color or contrast compared to other icons) to indicate that it is closed. If interface 702 is subsequently closed and the user returns to the interface, the control application may now not display the icon. Other variations are also possible.
[0141] Turning to icon 704, as indicated, this icon can be selected by the user and allows the user to turn off all lighting controls, thereby shutting down the currently active lighting loads in the load control system 210a. Upon detecting / determining that the user has selected the icon, the control application can transmit one or more messages to the system controller 250a, instructing the system controller to turn off all lighting controls / lights. Once completed, the system controller 250a can provide a response to the control application (e.g., automatically or in response to a query) indicating that the lighting controls are now off. In response, the control application can, for example, change the number associated with icon 622 to "0" (or, for example, not display a value), and, for example, remove all icons 704 from interface 702 or change the appearance of said icons. Since all lighting controls / lights are off, the control application can also deactivate icon 704 (where deactivation can include making the icon unselectable by the user and / or changing the appearance of icon 704, for example by changing the color or contrast of said icon compared to other icons, removing the icon from interface 702, etc.). Once the lighting control device returns to the ON state (e.g., a light is turned on by a user in user environment 202a), in addition to increasing the number associated with icon 622 to "1" and displaying icon 704 representing the lighting control device in interface 702, the control application can also activate / reactivate icon 704 (wherein activation may include allowing the user to select the icon and / or change the appearance of icon 704, such as by changing the color or contrast of said icon compared to other icons, displaying the icon in interface 702, etc.). It should be recognized that other instances are also possible, such as interface 702 also / alternatively including a "Turn on all lights" icon, which, upon selection, can cause the control application to send one or more messages to the system controller to turn on all lights in the user environment (or turn on a pre-programmed set of lights). Similarly, such a user action can cause the control application to increase the number associated with icon 622 and display the corresponding icon 706. As an alternative and / or in addition to selecting icon 704, the user may also select icon 706, and said icon allows the user to individually control the lighting control device, and thus control the lamp / lighting load associated with the icon. (It should be recognized that, alternatively, if the control application is configured to display icon 706 in a manner that indicates the corresponding lighting control device to be off, the user can continue to select said icon to control said device.) After detecting / determining that the user has selected a given icon from icon 706, the control application may display an interface for the user to control the corresponding device.
[0142] For example, assuming the control application detects / determines that the user has selected icon 706 labeled "kitchen ceiling light", the control application can display... Figure 6DThe control interface 708 shown is an example where the light is controlled as a single unit in a common state. For example, control interface 708 can be shown separately or overlaid on interface 702. It should be understood that control interface 708 is an example, and other controls are possible. The control application can determine whether the "kitchen ceiling light" is configured as a dimmable light or simply as an on / off light based on information provided by the system controller (e.g., according to a type indicator), and can display an appropriate control interface based on this determination. In this example, the "kitchen ceiling light" can be configured as a dimmable light, so the control application can display control interface 708 via a movable / slidable actuator 710 (e.g., a vertically movable actuator) that can be executed / moved by the user. As in this example, the control application can initially display actuator 710 to provide the user with an indication of the current dimming state of the light (e.g., the actuator is approximately halfway along the possible path of the light). Based on the user's detection of movement of actuator 710 (e.g., increasing or decreasing the light intensity, turning off the light, etc.), the control application can send one or more messages to system controller 250a to instruct the controller to reconfigure the lighting control device / lamp based on the user's instructions. If the user turns off the light, this update can be reflected in icon 622 (e.g., reducing the number) and interface 702 by removing or changing the appearance of icon 706 corresponding to the "kitchen ceiling light," as discussed above. Figure 6D As shown, the control interface 708 may also include an optional "edit" icon 712, which, when selected, enables the control application to display a user interface that allows the user to reconfigure the corresponding lighting control device / lamp (here, the "kitchen ceiling light"). For example, see reference... Figure 6EThe diagram illustrates an instance configuration interface 790 that a control application may display to a user upon detecting a selection of the "Edit" icon 712. Interface 790 may include a field 791 and / or an actuator / icon 791' configured to enable the user to change the type indicator associated with the lighting control device (here, "ceiling light") (e.g., via a dropdown menu of a defined type obtained through execution of actuator 791', free text field 791, etc.). The interface may also include an actuator / icon 792 configured to enable the user to change the location indicator associated with the lighting control device (here, "kitchen") (e.g., via a dropdown menu of a defined location obtained through execution of actuator 792). Interface 790 may include an actuator / icon 793 configured to enable the user to change the icon associated with the lighting control device / lamp (e.g., via a dropdown menu of a defined icon obtained through execution of actuator 793). The interface may include an actuator / icon 794 configured to allow a user to adjust or configure the dimming level of a lighting control device / lamp, such as a low-end adjustment level (e.g., controlling the lowest illumination level of the lamp) and / or a high-end adjustment level (e.g., controlling the highest illumination level of the lamp) (e.g., via a drop-down menu of the defined adjustment level obtained via execution of actuator 794). Interface 790 may include an actuator / icon 795 configured to allow a user to adjust or configure the dimming level of the corresponding lamp of the lighting control device to be controlled by either forward or reverse phase dimming (e.g., via a drop-down menu obtained via execution of actuator 795). Similarly, the control application may display editable features (e.g., adjustment and phase) of the lighting control device based on the determination that the lighting control device controls a dimmable lamp. The interface may also include a "Remove Device" icon 796. Execution of this icon 796 may cause the control application to instruct the system controller to remove the lighting control device from the load control system. Assuming a user makes changes to the lighting control device through interface 790, once completed, the user can choose to "Save" or "Cancel" as shown on the interface (although other mechanisms are also possible), such as returning to control interface 708 and saving or not saving the changes / configuration. Any saved changes made by the user regarding the lighting control device can be transmitted by the control application to the system controller, which can then reconfigure the lighting control device accordingly. It should be recognized that control interface 708 and configuration interface 790 are examples, and other controls are also possible. The user can exit control interface 708 by touching an area outside of interface 708 on the display of network device 680. Other examples are also possible.
[0143] return Figure 6COnce the user completes interface 702, the user can select icon 714 (the "Done" icon, but other icons can also be used). After detecting / confirming that the user has selected icon 714, the control application can display interface 610 to the user again, such as... Figure 6A As shown.
[0144] Turn now Figure 6A Icon 624, as indicated, can be a shading device icon that indicates to the user the number of shading devices within the load control system 210a that have a corresponding shading device currently open / closed (where open / closed can be any shading device state other than the fully closed position). (It should be recognized that while shading device icon 614 is discussed herein as associated with shading devices, it can also be associated with, for example, curtains, blinds, or Venetian blinds, as well as other types of curtain coverings. Alternatively, section 620 may include other icons for such devices.) Similar to lighting control devices, a given shading device can control more than one shading device (e.g., multiple shading devices covering multiple different windows as a single unit), and these shading devices can be controlled simultaneously (or can be configured to individually control these shading devices to different states). According to one example, a control application can treat a given shading device and its corresponding shading device as a single device. In this example, if multiple light-shielding objects controlled by the light-shielding device are in an open / closed state, the control application can count this as one (1) relative to the number associated with icon 624, regardless of the actual number of light-shielding objects controlled by the device. Nevertheless, it should be recognized that the number associated with icon 614 can represent the actual number of light-shielding objects controlled by each lighting control device. Here, the control application can view each light-shielding object controlled by a given light-shielding device individually. In this example, the number associated with icon 624 can represent each light-shielding object. Therefore, if two light-shielding objects controlled by the light-shielding device are in an open / closed state, the control application can count this as two (2) relative to icon 624. For descriptive purposes, the control application is described herein from the perspective of the light-shielding device, where the light-shielding device and its corresponding light-shielding object are considered as a single unit. The control application can determine the number of currently open / closed light-shielding objects based on information obtained from system controller 250a. In this example, the control application has determined, based on information received from the system controller 250a, that three shading devices have corresponding shading objects currently open / closed (where open / closed may include shading objects in a partially open / closed state). Similarly, for example, the control application and / or the system controller may perform a count to determine this number. The control application can do so by, as... Figure 6AThe number “3” shown in association with icon 624 indicates this determination to the user; however, the control application may display the number in other ways. In addition to displaying the number of light-shielding devices with light-shielding objects determined to be currently open / closed, similar to the discussion regarding icon 622 for lighting control devices, the control application may also proactively update the count displayed by icon 624, for example, based on the system controller 250a actively monitoring the status of light-shielding objects in the user environment (e.g., due to the user raising and lowering light-shielding objects in the environment) and asynchronously and / or, for example, reporting this information to the control application as requested from the system controller 250a regarding the status of the controlled devices / light-shielding objects. In this way, icon 624 allows the user to quickly and easily determine from the network device 680 whether any light-shielding objects are open / closed in the user environment. If it is determined that no light-shielding objects are currently open / closed, the control application may display the value “0” using icon 624, may display no value without using the icon, or may not display the icon at all (thus indicating that no light-shielding objects are open / closed, etc.). Other variations are also possible. For example, instead of displaying the number using icon 624, the control application could display the icon when any shade is open / closed, and not display the icon when all shades are closed / unclosed. As yet another example, icon 624 could indicate the number of shades currently closed / unclosed.
[0145] Icon 624 can also be selected by the user. After detecting / determining that the user has selected icon 624, the control application can display the following to the user via network device 680: Figure 6F The graphical user interface 720 is shown. Interface 720 may continue to display to the user icon 624 and the number of light-shielding devices with light-shielding objects currently determined to be open / closed. Interface 720 may also include a "All Open" icon 724 (but other text and / or icons may also be used) and / or may also include a "All Closed" icon 726 (but other text and / or icons may also be used), both of which can be selected by the user. Interface 720 may also include a corresponding icon 716 for each light-shielding device with a corresponding controlled light-shielding object currently open / closed (again, according to this example, the control application can be configured to treat the light-shielding device and its corresponding light-shielding object as a unit, representing the unit uniformly as a single icon. Alternatively, each light-shielding object controlled by the light-shielding device may be represented by an icon in interface 720 or a combination thereof). Each of these icons 716 can also be selected by the user. In this example, as shown by icon 624, three icons 716 are shown in conjunction with the value "3". According to another example and / or alternative examples and as... Figure 6FAs shown, interface 720 may also include corresponding icons 718 (three shown here) for each shading device currently closed / pulled down in relation to the corresponding controlled shading in the load control system. Each of these icons 718 can also be selected by the user. The control application can provide the user with visual indications of the status of all shading in the load control system. Assuming the control application is configured as follows... Figure 6F As shown in the diagram (i.e., both icons 716 and 718 are shown), the control application can use one or more visual tools / indicators when displaying the corresponding icons 716 and 718 to indicate which shading devices of the load control system have open shading and which have closed shading. As an example, the control application can change the appearance of the icons for open shading compared to closed shading, for example, in... Figure 6F In one example, different colors and / or contrasts are used between the icons. As another example and / or further examples, the control application may use different icons for open shades compared to closed shades. In one example, the icon representing an open shade may have an icon showing a partially open shade, and the icon representing a closed shade may have an icon showing a closed shade. Other examples are also possible.
[0146] Similar to Figure 6C The lighting control device, control application can also use location indicators and / or type indicators to display the location and / or function of the corresponding shading device / shading object in the user environment using each icon 716 and 718 (in this example, text information such as "shading object to the left of the kitchen", "shading object to the center of the kitchen", "shading object to the right of the kitchen", "shading object to the left of the living room", "shading object to the center of the living room", and "shading object to the right of the living room" is used, but other mechanisms can also be used, such as separating icons by location, with... Figure 6A (similar to section 660).
[0147] Similar to Figure 6CThe lighting control device allows the control application to proactively update icons 716 and 718 in the user interface 720 as the state of corresponding shading objects in the user environment changes. For example, if the user moves the "kitchen left shading object" from an open state / position to a closed state / position in the kitchen, the control application can receive an indication of this change from the system controller 250a (e.g., automatically or in response to a query from the control application) and change the corresponding icon in the display 720 to have the icon appearance represented by icon 718. Additionally, the control application can decrease the count associated with icon 624. Similarly, if the user moves the "living room left shading object" from a closed state / position to an open state / position in the kitchen, the control application can receive an indication of this change from the system controller 250a and change the corresponding icon in the display 720 to have the icon appearance represented by icon 716. Furthermore, the control application can increase the count associated with icon 624.
[0148] Turning now to icon 724 on user interface 720, this icon allows the user to open all shades within load control system 210a. Upon detecting / determining that the user has selected icon 724, the control application can transmit one or more messages to system controller 250a, instructing the system controller to open all shades. Once complete, system controller 250a can provide a response to the control application (e.g., automatically or in response to a query from the control application) indicating that the shades are now open. According to one example, “open” all shades could cause the system controller to control each shade to its corresponding fully open state. According to another example, the system controller could, for example, store a defined position (e.g., a user-defined position) for each shade, to which the shade should move in response to a “all open” request. Other variations are also possible. In response, the control application can display, as shown below... Figure 6G The example interface is shown. Specifically, the control application can change the value associated with icon 624 to indicate a new number of light-shielding devices with the corresponding light-shielding open (6 in this example), and can change the appearance of icons 716 / 718 as needed to indicate open light-shielding (in... Figure 6G In the examples, all light-blocking icons 716 / 718 are displayed as open light-blocking objects. It should be noted that in... Figure 6GSince all light-blocking elements are open, the control application can deactivate icon 724 (deactivation can include making icon 724 unselectable by the user and / or changing the appearance of icon 724, such as by changing the color or contrast of the icon compared to other icons, removing the icon from interface 720, etc.). If the light-blocking elements are subsequently closed (e.g., by the user in user environment 202a), the control application can activate / reactivate icon 724 (activation can include making the icon selectable by the user and / or changing the appearance of icon 724, such as by changing the color or contrast of the icon compared to other icons, displaying the icon in interface 720, etc.), in addition to, for example, reducing the number associated with icon 624 to "1" and accordingly changing the icons in interface 720 to display the closed light-blocking elements. As for icon 726, this icon allows the user to close all light-blocking elements within the load control system 210a. After detecting / determining that the user has selected icon 726, the control application can send one or more messages to system controller 250a, thereby instructing the system controller to close all light-blocking elements. Once completed, the system controller 250a can provide a response to the control application (e.g., automatically or in response to a query from the control application) to indicate that all shading is now closed. In response, the control application can display, as shown below... Figure 6H The example interface is shown. Specifically, the control application can change the value associated with icon 624 to, for example, "0", or display no value at all, and can change the appearance of icons 716 / 718 as needed to indicate an off light shield (in... Figure 6H In this example, all light-blocking icons 716 / 718 are displayed as closed light-blocking objects. It should be noted that since all light-blocking objects are closed, the control application can deactivate icon 726. If the light-blocking object is subsequently opened (e.g., by a user in user environment 202a), the control application can activate / reactivate icon 726, in addition to, for example, increasing the number associated with icon 624 to "1" and accordingly changing the icon in interface 720 to display the open light-blocking object. It should be recognized that when the user initially selects icon 624 on interface 610 to display interface 720, the control application can activate / deactivate icons 724 and 726 based on the open / closed state of the light-blocking objects in load control system 210a.
[0149] As an alternative to selecting icons 724 and / or 726, the user can select any one of icons 716 / 718 to individually control the light-shielding device and thus the light-shielding object. After detecting / determining that the user has selected a given icon from icons 716 / 718, the control application can display an interface to the user for controlling the corresponding light-shielding device and thus the light-shielding object. For example, assuming the control application detects / determining that the user has selected icon 716 labeled "Light-shielding object on the left side of the kitchen" in interface 720, the control application can display... Figure 6I The control interface 728 shown (in this example, if the control device controls more than one shading object, the shading object can be controlled to a common state). For example, control interface 728 can be shown alone or superimposed on interface 720. It should be recognized that control interface 728 is an example, and other controls are also possible. Here, control interface 728 is shown with a vertically movable / sliding actuator 730 that can be executed by the user (again, the control application can determine the appropriate control interface to display to the user based on information provided by the system controller (e.g., according to a type indicator), thereby controlling the selected device based on the device's capabilities). The control application can display actuator 730 as in this example to provide the user with an indication of the position of the corresponding shading object (i.e., the actuator is located approximately halfway along the possible path of the shading object to indicate, for example, that the shading object is partially closed / pulled down). Based on the user's detection of movement of actuator 730 (e.g., raising or lowering the shading object, etc.), the control application can transmit one or more messages to system controller 250a to instruct the system controller to reconfigure the "kitchen left-side shading object" based on the user's instructions. If the user closes the light shield, similar to what was discussed above, this update can be reflected in icon 624 (e.g., the displayed value decreases) and interface 720 (e.g., the appearance of the icon). Similarly, if the light shield was initially closed and is now opened via actuator 730, similar to what was discussed above, this update can be reflected in icon 624 (e.g., the displayed value increases) and interface 720 (e.g., the appearance of the icon). Figure 6I As shown, the control interface 728 may also include an optional "edit" icon 732, which, when selected, enables the control application to display a user interface that allows the user to reconfigure parameters associated with the shading device on the left side of the kitchen. The user can exit the control interface 728 by touching an area outside the display screen of the network device 680. Other examples are also possible.
[0150] same, Figure 6FUser interface 720 is one example. As another example, after detecting that a user has selected icon 624, the control application may display only the corresponding icon 716 for each light-shielding device with a currently open / closed light-shield in the graphical interface 720, and may include only the "All Closed" icon 726 to close the respective open light-shields (i.e., the interface 720 may not include the icon 718 and / or control icon 724 indicating currently closed light-shields). As another example, as shown above, light-shield icon 624 may alternatively indicate the number of light-shields currently closed / closed. In this example, after detecting that a user has selected icon 624, the control application may display only the corresponding icon 718 for each light-shielding device with a currently closed / closed light-shield in the graphical interface 720, and may include only the "All Opened" icon 724 to open the respective closed light-shields (i.e., the interface 720 may not include the icon 716 and / or control icon 726 indicating currently open light-shields). Further examples are also possible. For example, interface 720 may be as follows: Figure 6F The operation is shown in the diagram, where icon 624 indicates the number of open light-blocking objects, and icons 716 and 718 are both present to indicate the status of all light-blocking objects. However, interface 720 may not include the "all open" icon 724 and / or the "all closed" icon 726.
[0151] return Figure 6F Once the user completes interface 720, the user can select icon 722 (the "Done" icon, but other icons can also be used). After detecting / confirming that the user has selected icon 722, the control application can display interface 610 to the user again, such as... Figure 6A As shown.
[0152] Turn now Figure 6A Icon 626, as indicated, can be a thermostat device icon that indicates the current temperature in user environment 202a to the user. Specifically, load control system 210a may include one or more thermostat devices controlling a corresponding HVAC system. The control application can determine the current temperature in user environment 202a using information obtained from system controller 250a based on the interaction between the system controller and the thermostat device. Based on the current temperature obtained from the system controller, the control application can determine a representative temperature reading for the user environment and display this reading (72 degrees in this example) / compare this reading with... Figure 6AThe icon 626 shown is associated with indicating this reading to the user. As an example, when the load control system includes a single HVAC system, the current temperature indicated by the control application via icon 626 can be the current temperature measured by the corresponding thermostat device. When the load control system includes two or more HVAC systems, the current temperature indicated by the control application via icon 626 can be the current temperature indicated by one of the thermostat devices, which the control application can select based on information received from the system controller to be used and / or information associated with the corresponding thermostat device. For example, assuming the user environment has a downstairs HVAC system and an upstairs HVAC system, the control application can always use the current temperature indicated by the downstairs thermostat, can use the current temperature indicated by the downstairs thermostat during the day (e.g., "daytime" can be provided by the system controller, such as 6 AM to 8 PM), and use the current temperature indicated by the upstairs thermostat at night (e.g., "nighttime" can be provided by the system controller, such as 8 PM to 6 AM), etc. Other variations are also possible, including the control application allowing the user to select which thermostat device to use and when it may be used (see reference). Figure 6K One example is discussed. As another example, the control application can use the average of the corresponding current temperatures measured by the corresponding thermostat unit of each HVAC system (e.g., determined by the control application and / or system controller). It should be recognized that when multiple HVAC systems exist, other mechanisms and / or mathematical formulas can be used to determine the temperature associated with icon 626. As another example (not shown in the figure), in addition to associating / displaying the current temperature with icon 626, the control application can also display an indication of the current heat and / or cooling setpoint temperature to which the thermostat unit is set. When multiple thermostat units / HVAC systems exist, the control application can determine which setpoint(s) temperature(s) to use in a similar manner to the current temperature. It should be recognized that the temperature values provided by icon 626 can be in Fahrenheit or Celsius and can be configured by the user.
[0153] For illustrative purposes only, it will be assumed that the load control system 250a includes two HVAC systems (upper and lower floors), each with a corresponding thermostat device, and that the control application displays the current temperature reading of the lower floor system via icon 626. In addition to displaying the current temperature, similar to the lighting device icon 622, the control application can also proactively update the current temperature displayed by icon 626, for example, based on the system controller 250a actively monitoring the current temperature measured by the lower floor thermostat and asynchronously and / or, for example, reporting this information to the control application as requested by the system controller 250a regarding the status of the lower floor thermostat device. In this way, icon 626 allows the user to quickly and easily determine the current temperature in the user environment 202a from the network device 680.
[0154] Icon 626 can also be selected by the user. After detecting / determining that the user has selected icon 626, the control application can display the following to the user via network device 680: Figure 6J The graphical user interface 740 is shown. Interface 740 can continue to display icon 626 and the current temperature reading to the user. Interface 740 may also include a "Raise All" icon 744 (but other text and / or icons may also be used) and / or may also include a "Lower All" icon 746 (but other text and / or icons may also be used), both of which can be selected by the user and allow the user to control the thermostat devices of the load control system sequentially / jointly, as described below. Interface 740 may also include a corresponding information section (also referred to herein as a pane) for each thermostat device in the load control system. In this example, the load control system 210a includes two thermostat devices, each of which may have corresponding information sections or panes 760 and 762 that provide corresponding status information and control for each thermostat device / HVAC system. In load control systems with two or more thermostat units / HVAC systems, the control application can be configured to allow the user to scroll information sections 760 and 762 (e.g., vertically) to display additional information sections or panes, one for each system. In one aspect, information sections 760 and 762 allow the user to control the respective thermostat unit individually. Figure 6JAs further shown, the control application can use location indicators and / or type indicators associated with each thermostat unit to display an indication of the location of the respective unit in the user environment in conjunction with each thermostat unit in information sections or panes 760 and 762 (in this example, text information such as "downstairs thermostat" and "upstairs thermostat" is used, but other mechanisms are also possible). Generally, the use of text information by the control application can make it easier for the user to identify the actual thermostat unit / HVAC system in the user environment referred to by information sections 760 / 762.
[0155] Taking information section or pane 760 as an example, the control application can display the current temperature reading 750 (here, 72 degrees Celsius) determined by the corresponding thermostat device for the thermostat / HVAC system. Similarly, when the corresponding thermostat device determines that the current temperature reading in the user environment has changed and the system controller 250a reports this change to the control application (e.g., automatically or in response to a query from the control application), the control application can proactively update the current temperature reading 750 displayed to the user. The control application can also display the setpoint temperature 756 (here, 70 degrees Celsius) to which the corresponding thermostat device is configured to control the corresponding HVAC system. Assuming the HVAC system has four modes, including heating mode, cooling mode, automatic mode, and off mode, one or more setpoint temperatures 756 may not be displayed. For example, if the thermostat is set to off, the setpoint temperature may not be displayed. If the thermostat is set to heating or cooling mode, a setpoint temperature 756 may be displayed, representing the temperature to which the HVAC system is set to heat or cool, respectively. If the thermostat is set to automatic mode, two setpoint temperatures can be displayed, representing the temperature the HVAC system is set to heat to and the temperature it is set to cool to. An indication can also be provided to the user of which of the two temperatures is the heating to and which is the cooling to. Information section 760 may also include optional icon controls 752 (two pairs if two setpoint temperatures are displayed) that allow the user to adjust the setpoint temperature 756 of the thermostat device. In this example, the "+" and "-" controls are used to raise and lower the setpoint temperature 756, respectively. It should be recognized that other control types can be used. Each execution of the "+" control by the user raises the setpoint temperature 756 by a predetermined number of degrees (e.g., one degree). Similarly, each execution of the "-" control by the user lowers the setpoint temperature 756 by a predetermined number of degrees (e.g., one degree). After detecting / determining that the user has selected one of the corresponding "+" and "-" controls of icon 752, the control application can transmit one or more messages to system controller 250a, thereby instructing the system controller to adjust the setpoint temperature of the thermostat device. Changes in the setpoint temperature can also be reflected in the setpoint temperature 756 of interface 740.
[0156] For example, information segment 760 may also include an optional "umbrella icon" 758. After detecting / determining that the user has selected the umbrella icon 758, the control application can expand information segment 760 to display additional controls / information to the user, such as... Figure 6KThe user interface 764 is shown (again, the controls displayed by the control application can be based on the performance / function of the thermostat unit determined according to information provided by the system controller). According to this example, the user interface 764 may include three control sections that allow the user to further control the downstairs thermostat / HVAC system. These control sections may include a mode control 766 that allows the user to select any of the following modes of the HVAC system, such as heating, cooling, automatic, and off modes as described above. The control application can display the current mode of the HVAC system (here, cooling) determined by the system controller via the mode control 766. The control section may further include a fan control 768 that allows the user to turn the HVAC fan on and off. The control application can display the current fan setting of the HVAC system (here, on) determined by the system controller via the fan control 768. Assuming the thermostat unit / HVAC system is programmable, the control section may further include a timer control 770 that allows the user to turn the timer on and off. The control application can display the current timer status (here, on) determined by the system controller via the timer control 770. After detecting / determining that the user has selected any of these controls (e.g., by touching the words "HEAT," "AUTO," or "OFF"), the control application can transmit one or more messages to the system controller 250a, instructing the system controller to adjust / reconfigure the thermostat unit. The user interface 764 may also include an optional "edit" icon 756, which, when selected, causes the control application to display a user interface that allows the user to reconfigure the thermostat unit's schedule. For example, if the control application transmits this information to the system controller 250a, the user may be able to adjust the on / off time, heating and cooling setpoint temperatures, etc.
[0157] Turn to Figure 6JIncluding "Raise All" icon 744 and "Lower All" icon 746, these controls allow the user to raise and lower the setpoint temperature 756 of the corresponding thermostat units of the load control system one after the other / together. It should be recognized that other control types can be used. Each execution of icon 744 by the user raises the corresponding setpoint temperature 756 of each thermostat unit (which may differ for each thermostat) by a predetermined number of degrees (e.g., one degree). Similarly, each execution of icon 746 by the user lowers the corresponding setpoint temperature 756 of each thermostat unit by a predetermined number of degrees (e.g., one degree). For example, if the HVAC system is set to automatic mode, the two setpoint temperatures of the system may move one after the other. For example, suppose the setpoint temperature of the downstairs thermostat unit / HVAC system (represented by section or pane 760) is 70 degrees, while the setpoint temperature of the upstairs thermostat unit / HVAC system (represented by section or pane 762) is 74 degrees. User action on icon 744 can raise the setpoint temperature of the downstairs thermostat / HVAC system to 71 degrees Celsius and the setpoint temperature of the upstairs thermostat / HVAC system to 75 degrees Celsius (assuming each execution of icon 744 results in a one-degree change). Similarly, again assuming the downstairs thermostat / HVAC system setpoint temperature is 70 degrees Celsius and the upstairs thermostat / HVAC system setpoint temperature is 74 degrees Celsius, user action on icon 746 can lower the downstairs thermostat / HVAC system setpoint temperature to 69 degrees Celsius and the upstairs thermostat / HVAC system setpoint temperature to 73 degrees Celsius (assuming each execution of icon 746 results in a one-degree change). After detecting / determining that the user has selected one of the corresponding icons 744 and 746, the control application can transmit one or more messages to the system controller 250a, thereby instructing the system controller to adjust the setpoint temperature of the thermostat device. The change in setpoint temperature can be reflected in the setpoint temperature 756 of each device.
[0158] Further reference Figure 6JIf a given user environment includes different types of temperature devices, the appearance of segments 760 and 762 may differ for each temperature device. Similarly, the control application can make this determination based on information received, for example, from the system controller and / or information stored on a network device. According to another aspect of the control application, when the load control system 250a includes multiple HVAC systems, as described above, the temperature associated with icon 626 may correspond to one of these systems. According to one example, the control application may use the temperature associated with the first or top thermostat device / HVAC system as shown in interface 740 (here, the thermostat device / HVAC system represented by segment 760). According to another aspect of the control application, the user can change the order of segments 760 and 762 displayed in interface 740 (e.g., the user can touch a given segment for at least a defined time period. Upon detecting a touch, the control application can activate the segment and allow the user to drag the segment up or down, for example, to change the order). After changing the order, the control application can now make the temperature associated with icon 626 track the new top segment. It should be recognized that the order in which segments 760 and 762 should be followed, and which segment icon 626 should be tracked, can be stored at the network device and / or system controller. It should also be recognized that other variations are possible, including, for example, the last segment of temperature tracking segments 760 and 762 associated with icon 626.
[0159] Once the user completes interface 740, the user can select icon 742 (the "Done" icon, but other icons can also be used). After detecting / confirming that the user has selected icon 742, the control application can display interface 610 to the user again, such as... Figure 6A As shown.
[0160] As instructed, Figure 6A The user interface 610 section 620 may also include other icons, such as... Figure 6LThe fan icon 776 shown indicates to the user the status of fan units within the load control system 210a, such as the number of currently active fans. Similar to lighting control devices, a given fan unit can control more than one fan, and can control these fans simultaneously. According to one example, the control application can treat a given fan unit and its corresponding fans as a single unit. In this example, the control application can count one relative to the number associated with icon 776 (1) as long as one fan controlled by the fan unit is active, regardless of the actual number of fans controlled by the unit. Nevertheless, it should be recognized that the number associated with icon 776 can represent the actual number of fans controlled by each fan unit. Here, the control application can view each fan controlled by a given fan unit individually. In this example, the number associated with icon 776 can represent each fan. Therefore, if two fans controlled by the fan unit are active, the control application can count this relative to icon 776 as two (2). For descriptive purposes, this document describes the control application from the perspective of a fan unit, where the fan unit and its corresponding fans are considered a single unit. The control application can determine the number of currently active fans based on information obtained from system controller 250a. Similarly, for example, the control application and / or system controller can perform a count to determine this number. In this example, the control application has determined, based on information received from system controller 250a, that two fan units have corresponding fans currently active (where active can include any speed other than off). The control application can, as... Figure 6LThe number “2” associated with icon 776 indicates this determination to the user. In addition to displaying the number of fan devices with the corresponding fan determined to be currently on, similar to lighting control device icon 622, the control application can also proactively update the number displayed with fan icon 776, for example, based on the system controller 250a actively monitoring the status of fans in the user environment (e.g., due to the user adjusting fans in the environment) and asynchronously and / or reporting this information to the control application, for example, because the control application typically requests the status of fans and / or control devices from the system controller 250a. In this way, fan icon 624 allows the user to quickly and easily determine from network device 680 whether any fans are on in the user environment. If it is determined that no fan is currently on, the control application can display the value “0” using icon 776, can display no value without using the icon, or can not display the icon at all (thus indicating that no fan is on, etc.). Other variations are also possible. For example, instead of displaying the number with icon 776, the control application can display the icon when any fan is on and not display the icon when all fans are off. As yet another example, icon 776 can indicate the number of fan units with all corresponding fans in the off state.
[0161] Icon 776 can also be selected by the user. After detecting / determining that the user has selected icon 776 from user interface 620, the control application can display the following to the user via network device 680: Figure 6M The graphical user interface 772 is shown. Interface 772 may continue to display to the user icon 776 and the number of fan units with fans currently determined to be on. Interface 772 may also include a "Turn off all fans" icon 778 selectable by the user (but other text and / or icons may be used). Interface 772 may also include a corresponding icon 780 for each fan unit with a corresponding fan determined to be on (again, according to this example, the control application can be configured to treat the fan unit and its corresponding fan as a unit, representing the unit uniformly as a single icon. Alternatively, each fan controlled by a fan unit may be represented by an icon in interface 702 or a combination thereof). Each of these icons may also be selectable by the user. In this example, as shown by icon 776, two icons 780 are shown in conjunction with the value "2". The control application can use location and / or type indicators associated with each fan unit to combine each icon with an indication of the location of the corresponding fan unit / fan in the user's environment (in this example, text information such as "downstairs bathroom fan" and "master bedroom fan" is used, but other mechanisms, such as separating icons by location, could also be used). Figure 6ASimilar to section 660, but only displaying the icon for the currently active device. Similar to interface 702, the control application can proactively update the icon 780 displayed to the user when a fan in the user environment changes state from on to off and from off to on. For example, when a user turns on a fan controlled by a fan device in the user environment, the control application can receive an indication of this change from system controller 250a (e.g., automatically or in response to a query from the control application) and display an additional icon 780 associated with the fan device in interface 772, incrementing the value by "1", as shown in icon 776. Similarly, as a fan controlled by a fan device turns off, the control application can receive an indication of this change from system controller 250a and remove the icon 780 associated with the fan device from interface 772 or change the appearance of the icon (e.g., change the color or contrast of the icon compared to other icons), as similarly described above. Other variations are also possible. For example, the control application can be similar to... Figures 6F to 6H The interface 720 configures the interface 772, and, as similarly described for shading objects, displays all fan units (on and off) in the load control system, including the status of each fan unit, and as... Figures 6F to 6HSimilar to the description of the shading device, the user is also allowed to control the fan units. Turning now to icon 778, as indicated, this icon is selectable by the user and allows the user to turn off all fan units, thereby shutting down the currently active fans in the load control system 210a. Upon detecting / determining that the user has selected the icon, the control application can transmit one or more messages to the system controller 250a, instructing the system controller to turn off all fans. Once completed, the system controller 250a can provide a response to the control application (e.g., automatically or in response to a query) indicating that the fan units are now off. In response, the control application can, for example, change the number associated with icon 776 to "0" (or, for example, not display a value), and, for example, remove icon 780 from interface 772 or change the appearance of said icon. Since all fan units / fans are off, the control application can also deactivate icon 778 (where deactivation can include making the user unable to select the icon and / or changing the appearance of icon 778, for example by changing the color or contrast of said icon compared to other icons, removing the icon from interface 772, etc.). Once the fan unit returns to the on state (e.g., turned on by a user in user environment 202a), the control application can activate / reactivate icon 778 (wherein activation may include allowing the user to select the icon and / or change the appearance of icon 778, such as by changing the color or contrast of said icon compared to other icons, displaying the icon in interface 772, etc.) in addition to, for example, increasing the number associated with icon 776 to "1" and displaying icon 780 representing the fan unit in interface 772. It should be recognized that other instances are possible, such as interface 772 also / alternatively including a "Turn on all fans" icon, which, once selected, can cause the control application to send one or more messages to the system controller to turn on all fans in the user environment (or to turn on a set of pre-programmed fans). Similarly, such a user action can cause the control application to increase the number associated with icon 622 and display the corresponding icon 780 accordingly. Other instances are also possible.
[0162] As an alternative to selecting icon 778, the user can also select icon 780, which allows the user to control the fan unit individually, and thus control the fan associated with the icon. (It should be recognized that if the control application is configured to display icon 780 in a manner indicating that the corresponding fan unit is off, the user can continue to select the icon to control the unit.) After detecting / determining that the user has selected a given icon from icon 780, the control application can display an interface to the user for controlling the corresponding fan unit / fan.
[0163] For example, suppose the control application detects / determines that the user has selected icon 780 labeled "Main Bathroom Fan" (in this example, the fan unit can control a corresponding fan) in interface 772, then the control application can display... Figure 6N The control interface 782 is shown. For example, the control interface 782 may be shown alone or overlaid on the interface 772. It should be recognized that the control interface 782 is an example, and other controls are also possible. The “main bathroom fan” may be a multi-speed fan, therefore, the control application (e.g., determining that the fan is a multi-speed fan based on the fan type indicator) may display the control interface 782, as shown here, having multiple fan speed actuators 784 that can be executed by the user (i.e., the control application may determine the appropriate control interface to display to the user based on information provided by the system controller (e.g., based on the type indicator), thereby controlling the selected fan device / fan based on the function of the fan device / fan). The control application may display the actuators 784 to provide the user with an initial indication of the current fan speed of the fan controlled by the fan device (e.g., highlighting the low-speed actuator in this example). Based on detecting the user's selection of one of the actuators 784, the control application may transmit one or more messages to the system controller 250a to instruct the system controller to reconfigure the fan device based on the user's instructions. If the user turns off the fan unit / fan, as discussed above, this update can be reflected in icon 776 (e.g., by reducing the count by 1) and interface 772 by removing or changing the appearance of icon 780 corresponding to "Main Bathroom Fan". Figure 6N As shown, the control interface 782 may also include an optional "edit" icon 784, which, when selected, enables the control application to display a user interface that allows the user to reconfigure parameters associated with the corresponding fan unit / fan. The user can exit the control interface 782 by touching an area outside the display screen of the network device 680. Other examples are also possible.
[0164] return Figure 6M Once the user completes interface 772, the user can select icon 774 (the "Done" icon, but other icons can also be used). After detecting / confirming that the user has selected icon 774, the control application can display interface 610 to the user again, such as... Figure 6A As shown.
[0165] As described above, section 620 can display additional status information beyond the status information discussed herein. For example, the control application can include one or more icons in section 620 to indicate alarms and / or system notifications, such as indications of low battery power / low battery count in the load control system (e.g., assuming the control unit has batteries), indications of alarms being triggered in user environment 202a (e.g., smoke alarm, carbon monoxide detector alarm, home security alarm), indications of communication errors (e.g., the system controller cannot communicate with one or more control units), etc. The user can select any such icon, thereby allowing the control application to display an interface to the user that will provide, for example, additional information and / or system controls. Assuming the load control system includes, for example, occupancy sensors, the control application can include icons in section 620 that provide indications of occupancy status in user environment 202a. Such icons can simply provide an indication of occupancy / unoccupied status and / or provide an indication of the number of people present in user environment 202a. The selection of such occupancy icons can allow the control application to display an interface to the user that provides additional information, such as, assuming various rooms have occupancy sensors, which rooms in the user environment are occupied and / or unoccupied. It should be recognized that the control application can determine occupancy in other ways, such as detecting changes in the status of control devices like lights, fans, and shades through user-executed controls in the user environment, or tracking door opening / closing via sensors. As another example, among other scenarios, the scenarios maintained by the system controller may include "Vacation Mode," "Away Mode" (which could be a scenario where the resident leaves home that day), and "Home Mode" (which could be a scenario where the resident returns home that day). Therefore, the control application may include one or more icons in section 620 that provide an indication of which mode / scenario is currently active in the environment. Selecting such an icon can cause the control application to display an interface to the user that allows, for example, the user to change the mode / scenario. Similarly, other examples are possible.
[0166] Turn now Figure 6OIn sections 640 and 660, after determining / detecting that the user has selected device label 642 (or the default configuration), the control application can provide an indication of label activation (e.g., as shown by underlined 643, but other methods may also be used, such as reverse highlighting, etc.), and can display an icon within information section 660, wherein the icon may represent one or more control devices of the load control system 210a. According to one example, all control devices may be displayed in section 660. According to another example, certain control devices configured to only turn on / off the lighting load and / or control the dimming level of the lighting load, such as thermostat devices or handheld / remote control buttons, may not be displayed in this section. According to another example, the control application can be configured by the user, allowing the user to decide whether to display such control devices in section 660. As indicated above, when the control application is launched, the control application may default to device label 642.
[0167] According to one example, when device label 642 is activated, the control application can subdivide segment 660 into one or more panes (three panes 802, 804, and 806 are shown here). Each pane can represent a location within user environment 202a. The control application can determine the location based on information received from system controller 250a, such as location indicators associated with various control devices. The control application can use each pane to provide an indication of the location represented by that pane. Here, text labels are used, but other mechanisms could also be used. Figure 6OIn an example, the control application may label pane 802 as "Kitchen," pane 804 as "Living Room," and pane 806 as "Master Bedroom." In each of panes 802, 804, and 806, the control application may also display a corresponding icon (e.g., icons 810a to 810d) for the control device when the control device and / or the load controlled by the control device is located within the corresponding location indicated by the pane. As shown, different icons can be used for different types of control devices. According to one example, icons for certain control devices may appear in multiple panes 802, 804, and / or 806. As an example, if it is determined whether to display the icon of a control device in a pane based on the location of a given control device, the icon may appear in the pane corresponding to that location. However, if it is determined whether to display the icon of a control device in a pane based on the location of the loads controlled by the control device, and these loads are located in multiple locations, the icon may be displayed in each corresponding pane corresponding to that location. For descriptive purposes, the preceding example may be assumed. Other variations are also possible. Similarly, the system controller may provide an indication of the type of icon the control application should use for each control device. As another example, the control application can use information provided by the system controller on each control device to determine which icon to use (e.g., a fan icon for a fan-type device; a shading icon for a shading-type device; a light-based icon for a lighting control device; a button icon for a button device, etc.). The control application can further associate each icon with an indication of a specific location / function of the control device and / or a corresponding load of the control device, as discussed similarly herein. For example, pane 802 has three different displayed icons, each with a corresponding text identifier (“ceiling light”, “chandelier”, and “button”). According to another aspect of interface 610, the order of panes 802, 804, and 806 can be statically defined. According to another aspect, the control application allows the user to change the order of panes 802, 804, and 806 (e.g., the user can touch a given pane for at least a defined period of time. Upon detecting a touch, the control application can activate the pane and allow the user to drag the pane up or down, for example, thereby changing the order. Other changes are also possible). It should be recognized that the order of display panes 802, 804, and 806 can be stored at the network device and / or system controller. It should also be recognized that other variations are possible.
[0168] The control application can initially display a maximum number of icons in each pane (e.g., three here). If there are more than three controls in a given location, the pane can include, for example, an "umbrella marker" 808. After detecting / determining that the user has activated / selected the umbrella marker 808, the control application can expand the corresponding pane to display additional icons representing additional controls in that location. Selecting the umbrella marker 808 again will collapse the pane back to three icons. As another example, by default, the control application can display all icons for all controls in a given location in each pane. Here, the execution of the "umbrella marker" 808 can collapse the pane to not display icons, and selecting the umbrella marker 808 again will expand the pane to display all icons. Other examples are also possible. Furthermore, segment 660 can be scrollable (e.g., vertically scrollable) to display additional panes representing additional locations. According to one example, refer to Figure 6P The example user interface is shown, in which scrolling information segment 660 reveals another pane 808, corresponding to the "office" location within user environment 202a, and having corresponding icons representing additional controls located in the office. In this example, as segment 660 is scrolled to reveal the additional pane below the "master bedroom" pane 806, segment 660 can expand, with segment 620 scrolling out / being moved out of the network device's display interface and segment 660 occupying this space, and the additional pane (here, pane 808) appearing below pane 806. For discussion purposes only, the scrolling here may be referred to as scrolling down or scrolling down. This "downward" scrolling can be achieved, for example, by "sliding" a finger vertically upward along interface 610 as is known in the art, by selecting a downward-pointing arrow, etc. Continued "downward" scrolling of segment 660 can cause the pane at the top of the segment (here, the "kitchen" pane 802) to disappear from segment 660, and cause the additional pane to appear at the bottom of segment 660 (below the "office" pane 808), assuming there are additional panes as well. Similarly, when segment 660 is scrolled in the opposite direction (for the purposes of discussion only, this may be referred to as scrolling up or scrolling upwards, and this scrolling can be achieved, for example, by "sliding" a finger vertically downwards along interface 610 as is known in the art, by selecting an upward-pointing arrow, etc.) to potentially reveal panes that may have scrolled out of segment 660, such as pane 802, panes at the bottom of segment 660 can disappear from segment 660 (e.g., pane 808), and additional panes can appear at the top of segment 660. Continuing to scroll "up" causes segment 660 to collapse upon reaching the top pane (here, "kitchen" pane 802), and interface 610 reappears for segment 620 to be redisplayed, as... Figure 6OAs shown. According to another example, segment 620 can be minimized without scrolling out of display interface 610, as referenced below. Figure 7A and 7B Further discussion. Based on another example, as a supplement or alternative to the above, in... Figure 6O Selecting device tab 642 in the configuration (e.g., by "touching" or "tapping") will expand segment 660 and disappear segment 620, as shown below. Figure 6P As shown. Similarly, segment 660 can also be scrollable. Likewise, in Figure 6P Selecting device tab 642 in the configuration (e.g., by "touching" or "tapping") will cause segment 660 to collapse and segment 620 to be redisplayed, as shown below. Figure 6O As shown.
[0169] According to another aspect of device label 642, the control application can display the icons in section 660 in a manner that provides an indication of the status / state of the corresponding control device, as discussed similarly herein. For example, the control application can change the appearance of the icons (e.g., change the color and / or contrast of the icons compared to other icons) to indicate the status / state of the corresponding control device (and / or the state of the corresponding controlled load of the control device) as described herein. For example, for the lighting control devices represented by icons 810a to 810d, in Figure 6O In the example, icons 810a to 810b are shown to indicate that the lighting load of the corresponding control device is on, and icons 810c to 810d are shown to indicate that the lighting load of the corresponding control device is off. Color and / or contrast can be used in a similar manner to icons representing other types of control devices. According to another example, different icons can be used to represent different states for a given type of device, for example... Figure 6F As shown, icon 716 represents an open light shield and icon 718 represents a closed light shield. Other examples are also possible. According to another aspect of section 660, as the state / condition of the corresponding control device / load changes, the control application can dynamically change the appearance of the icons in section 660 (e.g., if the user turns off the light in the user environment, the control application can change the appearance of the lighting control device icon in section 660 to indicate the changed state, as similarly described herein). Typically, the state / condition of the control device indicated by the icons in section 660 can be matched with the state / condition of the control device indicated by the icons in section 620 and the interface corresponding to these icons.
[0170] According to another aspect of device label 642, the icon shown in section 660 can be selected by the user. After determining / detecting that the user has selected a given icon, the control application can display a control interface to the user to control the corresponding device, such as a similar interface to the device label 642. Figure 6D , Figure 6E , Figure 6I and Figure 6N As shown and discussed.
[0171] As another example, suppose Figure 6O Icon 810e represents, for example, a button control device with four buttons located in a kitchen. The buttons are configured to control one or more control devices, such as one or more lighting controls / lighting loads, shades, and speakers, and are programmed using a set of scenes (e.g., a set of buttons each controlling / configuring a corresponding scene). These scenes could include, for example, an "Off" scene to turn off the lighting loads; a "Dining" scene to set the lighting loads, shades, and speakers to a predefined dining state; a "Cooking" scene to set the lighting loads and speakers to predefined settings favorable to cooking; and a "Bright" scene to set the lighting loads to a fully on state. This is just one example. The control application determines / detects that the user has selected... Figure 6O The icon 810e indicates that the control application can display a control interface to the user, such as... Figure 6Q The control interface 812. Using information provided on the button control device by the system controller 250a, the control application can display the control interface 812 to represent the actual button. For example, the control interface 812 may have multiple selectable scene actuators 814 (shown here as, for example, buttons), each actuator representing and labeled as one of the scenes of the actual button press. The control application can further display the actuators 814 to provide the user with an indication of the current scene setting of the button (i.e., shown here, for example, as the "Dining" button being selected). Based on detecting / determining that the user has selected one of the scene actuators 814, the control application can transmit one or more messages to the system controller 250a to instruct the controller to reconfigure the button / corresponding lighting load, shade, and / or speaker according to the user's instructions, thereby setting the corresponding lighting load, shade, and / or speaker of the kitchen to the selected scene. Figure 6PAs further shown, the control interface 812 may also include an optional "Edit" icon 816, which, when selected, allows the control application to display a user interface that allows the user to reconfigure the scenes of the actual button controls (e.g., change one or more scene configurations) by sending one or more messages to the system controller 250a. These changes can also be reflected in the control interface 812. According to one example, before navigating to the "Edit" icon, if a given location (e.g., "kitchen" in this example) includes multiple button controls that are all configured identically (e.g., each button includes the same number of scene buttons and controls the same electrical load, and pressing the same button on any given button produces the same scene on the load), the control application may display only one icon 810e representing all the button controls in pane 802 (according to this example). Editing the buttons, as described below, allows the control application / system controller to reconfigure each button control within the load control system to the same configuration. According to yet another example, compared to when the "Off" scene is active, the control application can display the button icons 810e of pane 802 differently depending on whether a scene other than the "Off" scene is currently active (e.g., changing the icon color and / or contrast). Other variations are also possible.
[0172] After navigating to the "Edit" icon 816 and confirming / detecting that the user has selected the icon, the control application can display it to the user via the visual display of the network device 680. Figure 6R The example configuration interface 901 is shown. Interface 901 may include a first section 902 associated with, for example, a type indicator associated with a button control device, and this section may allow the user to change the type indicator (here, "button") associated with the button control device via a control application. Section 902 may be, for example, a drop-down menu and / or any text field, etc. Interface 901 may also include a section 903 associated with, for example, a location indicator associated with the button control device, and this section may allow the user to change the location indicator (here, "kitchen") associated with the button control device via a control application. According to this example, the button control device is currently indicated as being located in the "kitchen". The word "kitchen" may be an optional icon that allows the user to change the location associated with the device, but other mechanisms may also be used. After determining / detecting that the user has selected the "kitchen" icon 903, the control application may display to the user, as shown below. Figure 6SThe example interface 909 is shown. The control application can list the possible locations / rooms 908 associated with the button controls in interface 909. As shown, the control application can provide an indication of the current location associated with the button controls. In this example, a checkmark is shown next to "Kitchen," but other mechanisms can also be used. The user can select any (or possibly more) of the locations / rooms 908. After detecting that the user has selected a new location / room, the control application can associate a checkmark with the new location, for example, by removing the checkmark from a previous location (as another example, the user might need to select a given checkmark location to deselect a location; other variations are also possible). Although not shown, interface 909 can allow the user to specify a location not shown in list 908. Once complete, the user can select either the "Cancel" icon 907 or the "Save" icon 906. Selecting the "Cancel" icon 907 causes the control application not to save any changes made by the user via interface 909, but instead returns the user to interface 901. Selecting the "Save" icon 906 allows the control application to save any changes made by the user via interface 909 and returns the user to interface 901.
[0173] Return to Figure 6R If the user changes the position associated with the button device via interface 909, the position can be reflected in segment 903. Interface 901 may also include corresponding panes or segments 905a to 905d, each corresponding to one of the scene actuators / buttons of the button device. Each pane 905a to 905d may include a name associated with the corresponding scene (again, "Bright," "Cooking," "Dining," and "Off"). The name may be an optional icon, but other mechanisms may also be used. Each pane may also include a brief description of the controls (lights, speakers, shades) associated with the scene (i.e., an indication of which controls are controlled by the given scene). By selecting one of the icons in panes 905a to 905d, the user can change the scene assigned to the corresponding button of the button control device. For example, after detecting / determining that the user has selected the "Bright" icon to change the Bright scene, the control application may display to the user... Figure 6TThe example configuration interface 910 is shown. Interface 910 may include corresponding icons 912a and 912b (two icons shown here, representing lighting control devices / lighting loads respectively) corresponding to control devices (lighting, shading, speakers, etc.) associated with the selected scene, and possible settings for each device / load in the scene (here, each lighting load in the scene is set to 100%). Icons 912a and 912b may be optional icons that, when selected by the user, allow the user to individually control settings such as the corresponding control device / load (e.g., dimming level, shading level, etc.) via the interface. Because a bright scene contains lighting devices, example interface 910 may also include optional control icons 911, which, when selected by the user, allow the user to change the dimming level (up and down) of the displayed lighting control devices / loads 912a and 912b sequentially / together. Any changes to the dimming level may be reflected in icons 912a and 912b. Interface 915 may also include optional icons 915 that allow the user to add and / or remove control devices associated with the bright scene.
[0174] For example, after detecting / determining that the user has selected icon 915, the control application can display to the user... Figure 6U The example configuration interface 916 is shown. The control application can list possible control devices / loads 917 in the load control system 210a in interface 916, which can be controlled by buttons, and the user can associate / add the control devices / loads to the current scene (here, the bright scene) and / or remove them from the current scene. According to one example, the control devices / loads 917 located in the same room as the buttons (here, the kitchen unit) can be listed first, followed by other control devices / loads in the load control system (here, the office desk lamp). As shown, various control devices / loads 917 can be selected / deselected by the user (e.g., selected control devices / loads 917 are specified by a "check mark") to add / remove devices from the scene. Interface 916 can further allow the user to configure levels (e.g., dimming level, shading level, etc.) for each selected device, for example, by selecting an icon associated with the control device and the additional interface shown. Interface 916 can further include control icons 918a and 918b, which allow the user to select all displayed control devices or deselect all control devices. Once complete, the user can select "umbrella marker" 920 (but other mechanisms can also be used) to return to... Figure 6TThe interface is 910. Upon returning to interface 910, the interface may include icons 912a / 912b reflecting the selections made in interface 916. Once complete, the user can select either the "Cancel" icon 913 or the "Save" icon 914. Selecting the "Cancel" icon 913 causes the control application not to save any changes made by the user via interface 910, but instead returns the user to interface 901. Selecting the "Save" icon 906 causes the control application to save the changes made by the user via interface 910 and returns the user to interface 901.
[0175] Referring again to interface 901, the interface may also include a "Delete Button" icon 904. Executing this icon causes the control application to instruct the system controller to remove the button control device from the load control system. Assuming the user has changed the button scene, once completed, the user can select an "umbrella icon" 921 (but other mechanisms may also be used) to return to, for example, interfaces 812 or 610. Any changes made by the user to the button control device can be transmitted by the control application to the system controller, which can then reconfigure the load control system, including the button control device, accordingly. Additionally, if the position of the button control device is changed, for example, via interface 909, the control application can, for example, move the corresponding icon in device label 642 to a new pane indicating the new position. Similarly, for example, if the button control device is removed from the load control system, the corresponding icon can be removed from device label 642.
[0176] According to another aspect, the button control device can communicate with other control devices to implement a scene. These other control devices can have corresponding icons as discussed herein, such as the icons in device label 642. When a scene is controlled via interface 812 or the actual button control device, the control application can change the appearance of such icons as described herein. Similarly, when the state of the control device changes as described herein, for example, when a scene is executed via interface 812 or the actual button control device, the control application can update the values represented by the icons in section 620. Other variations are also possible.
[0177] It should be recognized that, Figures 6R to 6U The interface is an instance, and other variations are also possible. For example, responding to user selection... Figure 6Q The "Edit" icon 816 on the control interface 812 allows the control application to be displayed to the user via the visual display of the network device 680. Figure 6V The example configuration interface shown is 901'. It is similar to... Figure 6RInterface 901' may include a first segment / field 902' associated with a name, for example, that is associated with a button control, and the first segment / field may be configured to allow a user to change the name associated with the button control (here, "button") via a control application. Interface 901' may also include an actuator 903' associated with a position indicator, for example, that is associated with the button control, and the actuator may be configured to allow a user to change the position indicator (here, "button") associated with the button control via a control application (e.g., by providing access to a menu / drop-down menu). Interface 901' may also include corresponding panes or segments 905a' to 905d', each pane or segment corresponding to one of the scene actuators / buttons of the button device. Each pane 905a' to 905d' may include a name associated with a corresponding scene (here again, "Bright," "Cooking," "Dining," and "Closed"). Each pane may be optional (e.g., via a corresponding icon or umbrella icon 923). Interface 901' may also include a "delete" icon 904', which may resemble the "delete" icon 904.
[0178] Assuming the control application detects a selection of one of the icons 923, the user can change the scene assigned to the corresponding button on the keypad control device. For example, after detecting / determining that the user has selected icon 923 associated with the "bright" scene, the control application can display... Figure 6WThe example configuration interface 916' is shown. The control application can list / display possible control devices / loads 917' in the load control system 210a within interface 916'. These control devices / loads can be controlled by buttons, and the user can associate / add these control devices / loads to the current scene (here, a bright scene) and / or remove them from the current scene (interface 916' may be scrollable). According to this example, the control devices / loads 917' are separated by location (e.g., "kitchen," "living room," "dining room," etc.). As shown, various control devices / loads 917' can be selected / deselected by the user (e.g., selected control devices / loads 917' are specified by a "check mark") to add / remove them from the scene. For selected control devices that are part of the scene (here, "main light" and "chandelier"), the control application can also display the device's level relative to the scene (here, both devices are shown as fully "on" as part of the bright scene) (similar indicators can be displayed for other control devices / loads, such as light-blocking elements). For selected control units that are part of the scene (here, "main lighting" and "chandelier"), interface 916' may also include corresponding icons or umbrella icons 919, for example, to configure the level of the unit. For example, in response to the control application detecting that the user has selected the icon 917 associated with "main lighting", such as Figure 6X As shown in the example, the control application can expand interface 916' to display control interface 922. Here, control interface 922 is shown as having a vertically movable / slidable actuator 922a that can be executed / slid by the user to change the lighting level, and also includes a set of buttons / actuators 922b (e.g., four here, one for setting the level to fully open, one for raising the level, one for lowering the level, and one for setting the level to off) (other variations are also possible). The control application can display actuator 922a, for example, to provide the user with an indication of the current setting of the corresponding device (here, fully open). In response to the user selecting actuator 922a and / or 922b, the control application can change the displayed level setting from "open" to a value representing the new level set by the user. Upon detecting a further selection of the icon 919 associated with the "main lighting", the control application can collapse interface 916', as shown in the example. Figure 6W As shown.
[0179] Interface 916' may also include instance optional icons / actuators 918a', 918b', and 918c' (but may also display fewer and / or additional icons). These icons allow users to more easily display control devices of interest in interface 916'. For example, icon 918a' can be toggled between selected and unselected. When selected, the control application can display, for example, "all" control devices in a load control system. Deselecting icon 918a' prevents the control application from displaying any control devices. Icon 918b' can also be toggled between selected and unselected. For example, when icon 918b' is selected, the control application can deselect icon 918a' (if it has been selected) and only display lighting control devices that are part of the load control system in interface 916'. Deselecting icon 918b' allows the control application to remove lighting control devices from interface 916'. Similarly, icon 918c' can be toggled between selected and unselected. For example, when icon 918c' is selected, the control application can deselect icon 918a' (if it has been selected) and only display the shading device as part of the load control system in interface 916'. When icon 918c' is deselected, the control application can remove the shading device from interface 916'. It should be recognized that both icons 918b' and 918c' can be selected to display both the lighting control device and the shading device. It should be recognized that other variations are also possible. The user may or may not save changes made via interface 916', as discussed similarly above. Any changes made by the user to the button control device can be transmitted by the control application to the system controller, which can then reconfigure the load control system accordingly. Similarly, changes can be reflected in other interfaces as discussed herein.
[0180] Figures 6Q to 6X The interface is compatible with various types of buttons, including handheld remote buttons for controlling various scenarios.
[0181] Overall, device label 642 allows users to easily identify control devices in different locations within the user's environment, determine the status of the control devices, and easily control the devices.
[0182] Turn now Figure 6YAfter determining / detecting that the user has selected scene tag 644, the control application can display instance interface 820. Interface 820 can be similar to interface 610, continuing to display section 620 and corresponding status information, and the scene tag is now displayed as active (e.g., as shown by underline 822, but other methods are also possible, such as reverse highlighting). When a scene tag is selected, the control application can configure section 660 to display information indicating one or more scenes that can be activated by the user. Specifically, as indicated above, system controller 250a can maintain information related to one or more pre-programmed scenes that can be executed by the user from the control application. Each scene may include a scene name, specific settings for one or more lights (e.g., dimming level), specific settings for one or more shades, etc. Other instances are also possible. The control application can obtain information about each scene from system controller 250a and display the corresponding information about these scenes to the user in information section 660.
[0183] like Figure 6Y As shown, the control application can subdivide segment 660 into multiple panes (three panes 824, 826, and 828 are shown here). Each pane can represent and / or contain information about each scene maintained by the system controller. For example, in each pane 824, 826, and 828, the control application can display optional icons representing the scene (e.g., icons 830a to 830c), and can further display information that can provide a scene description (e.g., text information such as "Wake Up," "Entertainment," and "Basement Closed"). Similarly, different icons can be used for different scenes, and the system controller can provide the control application with instructions, for example, on which icon to display. If there are more scenes than segment 660 can accommodate, the segment can be vertically scrollable, for example, to display additional scenes, similar to those described above. Figure 6O and Figure 6P The description.
[0184] According to another aspect of scene label 644, the control application can display icons 830a to 830c in segment 660 in a manner that provides an indication of scene status / state (i.e., whether the scene is active or inactive). For example, the control application can change the appearance of the icons (e.g., change the color and / or contrast of the icons compared to other icons) to indicate the status / state of the corresponding scene.
[0185] After determining / detecting that the user has selected a given icon 830a to 830c, the control application can send one or more messages to the system controller to indicate whether the scene has been selected or not (to activate or deactivate the scene). The system controller can then sequentially configure the corresponding control devices based on whether the scene is activated or deactivated (e.g., on or off). When a device changes its state due to a change in scene, the control application can update segment 620 accordingly.
[0186] like Figure 6Y As further illustrated, each scene may also include optional "pencil" icons 832a to 832c, which, when selected, can cause the control application to display an interface to the user that allows the user to reconfigure the scene. Reconfiguring a scene may include adding or removing one or more controls from the scene, changing the settings (e.g., dimming level) of one or more controls that are part of the scene, deleting the scene, etc. The control application may then transmit the changes to the system controller via one or more messages.
[0187] For example Figure 6Y As shown, segment 660 may include an "Add Scene" icon 834, which, when selected by a user, could cause the control application to display an interface that allows the user to create a new scene. The creation of a new scene could cause the control application to transmit one or more messages instructing / defining the new scene to the system controller, and could further cause the control application to add the scene to segment 660, allowing the user to activate the scene. It should be recognized that other variations are also possible.
[0188] Turn now Figure 6ZAfter determining / detecting that the user has selected the timetable label 646, the control application can display instance interface 840 to the user. Interface 840 can be similar to interface 610, continuing to display section 620 and corresponding status information, and the timetable label is now displayed as active (e.g., as shown by underline 848, but other methods may also be used, such as reverse highlighting, etc.). When a timetable label is selected, the control application can configure section 660 to display information corresponding to one or more timetables that the system controller is configured to execute. Specifically, as indicated above, system controller 250a can maintain information related to one or more pre-programmed timetables that the system controller can automatically execute. Each timetable may include a timetable name, specific settings for one or more lights (e.g., dimming level), specific settings for one or more shades, and the time / date when the system controller should activate / deactivate the timetable, etc. Other instances are also possible. The control application can obtain information about each timetable from the system controller and display the corresponding information about these timetables to the user in information section 660.
[0189] like Figure 6Z As shown, the control application can subdivide segment 660 into multiple panes (three panes 842, 844, and 846 are shown here). Each pane can represent and / or contain information about each schedule maintained by the system controller. For example, in each pane 842, 844, and 846, the control application can display information that provides a description of the schedule (e.g., text information such as "front porch light," "festival light," and "shade on / off"). This information may further include a description of when the corresponding schedule is activated. If there are more schedules than segment 660 can hold, the segment can be vertically scrollable, for example, to display additional schedules, similar to those described above. Figure 6O and Figure 6P The description.
[0190] like Figure 6Z As further shown, each schedule may also include an optional "pencil" icon 852a to 852c, which, when selected, allows the control application to display an interface to the user that allows the user to reconfigure the schedule. Reconfiguring the schedule may include adding or removing one or more control devices from the schedule, changing the settings of one or more control devices that are part of the schedule (e.g., dimming level), deleting the schedule, changing the timing of the schedule, etc. The control application can then transmit the changes to the system controller via one or more messages for implementation. Other variations are also possible.
[0191] For example, refer to Figure 6AAAnother example interface 840' is shown, where the schedule label is active. Interface 840' can be similar to interface 840, where section 660 is subdivided into one or more panes (three panes 842', 844', and 846' are shown here). Each pane can represent and / or contain information about each schedule maintained by the system controller. For example, in each pane 842', 844', and 846', the control application can display information that provides a description of the schedule (e.g., text information such as "Hallway Lights On," "Hallway Lights Off," and "Wake Up"). The information can also include a description of when the corresponding schedule should be activated on the corresponding day of the week (e.g., the "Wake Up" schedule is only scheduled for weekdays). According to this example, the control application can also display corresponding icons 953a, 953b, and 953c for each schedule. The control application can combine each icon / schedule (e.g., inside the icon) to display information about the time the schedule is activated / starts running. According to this example, the user can configure the schedule to be activated relative to astronomical time (e.g., relative to sunrise and sunset) or relative to a set clock time (e.g., 9:00 AM). In this example, the "Hallway Lights On" and "Hallway Lights Off" schedules are configured to be astronomical schedules activated relative to sunset and sunrise, respectively. Therefore, these schedules may begin at different clock times each day of the year, as sunset and sunrise can vary daily. In this example, the "Wake Up" schedule is clock-time related and begins at the same static time of 6:30 AM on every weekday. Figure 6AA As further shown, each schedule may also include optional “pencil” icons 852a’ to 852c’, which, when selected, can cause the control application to display an interface to the user that allows the user to reconfigure the schedule.
[0192] In one example, when a schedule is set to be active / started, the control application can display the schedule in chronological order within segment 660. Therefore, the current schedule or the next schedule to be activated / run (if there is no current schedule) can be displayed first (e.g., at the top of segment 660), then the next schedule to be activated, and so on. As a schedule completes (ends), the control application can remove that schedule from the top of the list and move other schedules up, potentially moving the removed schedule to the bottom of the list (other sorting is also possible). Because some schedules may be related to astronomical time, the control application may change the order of the displayed schedules daily throughout the year, as these schedules do not start at the same statically set time every day.
[0193] According to another aspect of interface 840', the control application can display the status of a given schedule to the user, where one or more possible states may exist. As an example, three states may exist, including (i) a deactivated state, where the schedule is not set to be active / running at its specified time (e.g., the schedule may be deactivated because the user has deactivated it, or because the schedule is not set to be active on the day of the week / today, etc.), (ii) an active-matched state, where the schedule is set to be active or is currently active at its specified time, and all control devices that are part of the schedule are currently in a state that matches the schedule, and (iii) an active-dismatched state, where the schedule is set to be active or is currently active at its specified time, but all control devices that are part of the schedule are not currently in a state that matches the schedule. It should be recognized that fewer or additional states are also possible. According to one example, the control application can use icons 953a to 953c to indicate the status of each schedule to the user, for example, by changing the icon, or by changing the appearance of the icon, for example, by color or reverse highlighting, etc. In this example, assuming it's Saturday afternoon at 3 PM, the sun is up and the hallway lights are off, the "Hallway Lights On" schedule could first be displayed as the next active timer at the top of segment 660, followed by the "Hallway Lights Off" schedule, and then the "Wake Up" schedule. The control application could display the "Hallway Lights On" schedule icon 953a as a schedule in an active-mismatch state because the schedule is set to be active at sunset but the hallway lights are off, thus currently not matching the schedule's configuration (this schedule's state can change to active-match once the hallway lights are on). Since the schedule is in an active-match state, the control application could display the "Hallway Lights Off" schedule icon 953b because the schedule is set to be active at sunrise, and the currently off hallway lights match the schedule's configuration. For example, when the schedule is in a deactivated state, the control application could display the "Wake Up" schedule icon 953c because the schedule is not configured to run on weekends. This is one example, and other examples are possible.
[0194] For example Figure 6Z and Figure 6AA As shown, segment 660 may include an "Add Event" icon 850 or an "Add Schedule" icon 850'. For example, when selected, the icon may cause the control application to display an interface to the user that allows the user to create a new schedule. The creation of a new schedule may cause the control application to transmit one or more messages instructing / defining the new schedule to the system controller, and may further cause the control application to add the schedule to segment 660.
[0195] It should be recognized that, for example, Figure 6A , Figure 6O , Figure 6Y and Figure 6Z The sections / panes 620, 640, and 660 of the graphical interface shown herein can be displayed in different orders. For example, when displayed on the visual display of the network device 680, section 620 of the graphical interface described herein is vertically positioned above section 640, and section 640 is vertically positioned above section 660. As another example, when the sections are displayed on the visual display of the network device 680, section 640 may be vertically positioned above section 660, and section 660 may be vertically positioned above section 620. Other orders are also possible. As another example, section 620 may be a vertically oriented pane / section (i.e., icons may be placed vertically rather than horizontally) compared to horizontally oriented panes. Here, for example, pane 620 may be located to the left or right of panes 620 and 640.
[0196] Nevertheless, as discussed herein, status section 620 can provide the user with a summary of the load control system 210a, and corresponding icons can provide the user with access to control devices that the user is more likely to want to control compared to other devices. Therefore, placing section 620 above sections 640 and 660 (i.e., at the top of the visual display of network device 680) makes this section more easily accessible to the user.
[0197] It should be recognized that other instances besides those described above are also possible. For example, see reference... Figure 7A Another example of a graphical user interface 1510 is shown, which can be initially displayed to the user via a network device 680 by the control application when the application is initially launched. Interface 1510 may, for example, resemble... Figure 6AThe interface 610 shown may include three sections or panes, including a status section 620, a menu selection / tab section 640, and an information section 660. According to this example and as discussed similarly above, section 620 of interface 1510 may include one or more icons indicating different status information of one or more control devices 220a within the load control system 210a. Here, a lighting device icon 1522, a shading device icon 1524, and a thermostat device icon 1526 are shown; however, as mentioned above, additional and / or other and / or fewer icons may be shown, such as an audio device icon and / or a fan device icon, depending on the control device 220a within the load control system 210a. Section 620 may be configured to be scrollable by the user (e.g., from left to right or up / down) to display additional icons, and / or may be configured to display multiple rows of icons to the user at once, again depending on the control device 220a within the load control system 210a. Based on this example, the status of the corresponding device can be displayed to the user by a control application via numerical values and / or text associated with icons, and especially with, for example... Figure 6A The number of icons stacked on top of each other can be displayed below the icons (here, "10 on", "3 on", "Current"). As another example, the status of lighting fixtures (and similarly, fan devices) in the "off" state can be displayed as "0 on" or "all off". For example, the status of light shields in the off state can be displayed as "0 on" or "all off". Similarly, other variations are possible, including... Figure 6A The format used. As described above, the icon shown in section 620 can be selected by the user, wherein the control application leads the user to a subsequent user interface (e.g., in response to the selection of icon 1522, leads to...). Figure 6C (Interface 702). Similarly, when the status of the control device changes, the status information associated with each icon can be dynamically / actively updated by the control application.
[0198] For example, see the reference above. Figure 6O , Figure 6Y and Figure 6Z Similarly, for example, when any of the device label 642, scene label 644, and timetable label 646 are active, segment 660 of interface 1510 can be vertically scrollable. As an example, using device label 642 as the active label, segment 660 can expand when segment 660 is scrolled "down" (and / or the pane expands) to display additional pane information, such as the "Master Bedroom" pane 1586 and / or additional information in the additional pane below the "Master Bedroom" pane 1586. This expands segment 660, where segment 620 scrolls out of and / or disappears from and / or moves out of the network device's display interface, and segment 660 occupies this space. Alternatively, and as... Figure 7B As shown, when segment 660 is expanded, segment 620 can be controlled by the application to compress or minimize it. For example, as Figure 7B As shown, icons such as 1522, 1524, and 1526 can be removed by the control application, but status information based on numbers and / or text can continue to be displayed for one or more types of devices to provide status information to the user (here, lighting devices are "10 lights on", shading devices are "3 shadings open", and thermostat devices are "currently 72°"). The displayed information and format are examples, and other examples are possible. The compressed / minimized section 620 of interface 1510 can be configured to be scrollable by the user (e.g., from left to right or up / down) to display additional status information, and / or can be configured to display multiple lines of information to the user at once. Alternatively, the compressed / minimized section 620 of interface 1510 may not be scrollable and may display status information for only a subset of the controlled devices. Which devices are displayed may be user-defined or not. When the status of the controlled devices changes, the status information shown in the compressed / minimized section 620 of interface 1510 can be dynamically / actively updated by the control application. According to one example, the compressed / minimized section 620 of interface 1510 can be configured to allow a user to select various parts (e.g., "10 lights on", "3 shades on", and "current 72°") via a control application, thereby leading the user to a subsequent user interface, as described above. According to another example, the compressed / minimized section 620 of interface 1510 can be configured such that, in response to a user selection of section 620, the section can be re-expanded by the control application and section 660 can be collapsed by the control application, thus returning to the previous state. Figure 7A The configuration shown. Segment 620 can then be configured to allow the user to select the icon to display, as described above. See also... Figure 7B Assuming an additional pane exists, continuing to scroll "down" on segment 660 can cause the pane at the top of the segment (here, the "Kitchen" pane 1582) to disappear from segment 660, and the additional pane to appear at the bottom of segment 660 (below the "Master Bedroom" pane 1586). Similarly, when segment 660 is scrolled "up" in the opposite direction (to possibly reveal a pane, such as pane 1582 that may have scrolled out of segment 660), the pane at the bottom of segment 660 can disappear from segment 660 (e.g., pane 1586), and the additional pane can appear at the top of segment 660. Continuing to scroll "up" (and / or collapsing the panes of segment 660) can cause segment 660 to collapse upon reaching the top pane (here, the "Kitchen" pane 1582), and segment 620 to unfold again, and interface 1510 reappears, as... Figure 7A As shown. According to another example, as a supplement and / or alternative to the above, in Figure 7A Selecting device label 642 in the configuration (e.g., by "touching" or "tapping") can cause section 660 to expand and section 620 to fold, as... Figure 7B As shown. Similarly, segment 660 can also subsequently be scrollable. Likewise, in Figure 7B Selecting device label 642 and / or segment 620 in the configuration (e.g., by "touching" or "tapping") will cause segment 660 to fold and segment 620 to unfold again, as shown. Figure 7A As shown. Therefore, the expansion and collapse of segments 620 and 660 can be achieved / obtained in various ways, including by scrolling and / or by selecting segment 620 and / or device label 642. Similarly, scene label 644 and timetable label 646 can operate in a similar manner.
[0199] Now for reference Figure 8A This illustrates another example of a graphical user interface 1610, which can be initially displayed to the user via a network device 680 by the control application when the application is initially launched. Interface 1610 may, for example, resemble... Figure 7A The interface 1510 shown may include three sections or panes, including a status section 620, a menu selection / tab section 640, and an information section 660. According to this example and as discussed similarly above, section 620 of interface 1510 may include one or more icons indicating different status information of one or more control devices 220a within the load control system 210a. Here, a lighting device icon 1622, a shading device icon 1624, and a thermostat device icon 1626 are shown. According to this example, the status icons are now arranged vertically instead of horizontally. Figure 8A Furthermore, the status of the corresponding device can be displayed to the user via numerical values and / or text associated with icons, and especially with, for example... Figure 6A The number of lights stacked on the icons shown can be displayed below the icons (here, "8 lights on", "3 light shields on", "current"). Nevertheless, it should be recognized that this can also be used in interface 1610. Figure 6A The format used is as described above. Similarly, other variations are possible. As another example, the status of a lighting device (and similarly a fan device) in the "off" state can be displayed as "0 lights on" or "all lights off". For example, the status of a shading device in the off state can be displayed as "0 shadings on" or "all shadings off". As described above, the icons shown in section or pane 620 can be selected by the user, wherein the control application leads the user to a subsequent user interface (e.g., in response to the selection of icon 1622, to...). Figure 6C(Interface 702). Similarly, when the status of the control device changes, the status information associated with each icon can be dynamically / actively updated by the control application.
[0200] according to Figure 8A In the example shown, load control system 210a includes three types of devices, including lighting control devices, shading devices, and thermostat devices. Therefore, interface 1610 displays three corresponding icons in section 620. As discussed herein, load control systems may include fewer, other, and / or additional control devices, and therefore section 620 may include fewer, other, and / or additional icons. According to one aspect of interface 1610, the default size configuration of sections 620 and 660 may be based on the number of icons within section 620 (i.e., the type of control device in the load control system). For example, when the load control system includes an increasing number of control device types, the control application may increase the default size of section 620 to display additional icons and decrease the default size of section 660. Similarly, when the load control system includes a decreasing number of control device types, the control application may decrease the default size of section 620 to display fewer icons and increase the default size of section 660. For example, as... Figure 8A As shown in the example, section 660 illustrates two panes 1682 and 1684 of the active device label 642 (similarly, if scene label 644 or timetable label 646 is active, section 660 may display information related to these labels). As another example, assuming the load control system 210a includes fewer types of control devices, section 620 may include fewer icons and corresponding status information. For example, refer to... Figure 8B Assuming the load control system 210a only includes lighting control devices, then section 620 may only include icon 1622 and the corresponding status information. Based on this example, with... Figure 8A In contrast, section 660 now occupies additional remaining space on interface 1610, where six panes 1682, 1684, 1686, 1688, 1690, and 1692 are shown (similarly, if scene label 644 or timeline label 646 is active, section 660 can display information related to those labels). According to another example and as... Figure 8CAs shown, assuming the load control system 210a includes not only lighting control devices, shading devices, and thermostat devices, but also audio devices and fan devices, then section 620 can now include five icons 1622, 1624, 1626, 1628, and 1630, along with associated status information. According to this example, section 660 is no longer displayed in interface 1610. According to this example, if the load control system also includes additional load control types, section 620 can be scrolled vertically to display the additional icons. It should be understood that... Figure 8A , Figure 8B and Figure 8C This is an instance, and other variations are also possible. For example, regarding... Figure 8C More than five icons can be displayed at once in segment 620. Similarly, fewer than five icons can be displayed in segment 620, where segment 620 still occupies space of 1610 on the screen, and segment 660 is not displayed.
[0201] Refer again Figure 8A Instances ( Figure 8B Instances can be operated in a similar way, as referenced above. Figure 7A and Figure 7B Similarly, for example, when any of the device tab 642, scene tab 644, or timetable tab 646 is active, segment 660 of interface 1610 can be vertically scrollable. As an example, using device tab 642 as the active tab, segment 660 can expand when segment 660 is scrolled "down" (and / or the pane expands) to display additional pane information, such as the additional pane below the "Living Room" pane 1684. Segment 620 occupies this space by controlling the application to scroll out of and / or disappear from and / or move out of the network device's display interface. Alternatively, and as... Figure 8D As shown, when segment 660 is expanded, segment 620 can be controlled by the application to compress or minimize it. For example, as Figure 8DAs shown, icons such as 1622, 1624, and 1626 can be removed, but the control application can continue to display status information based on numbers and / or text, or variations thereof, for one or more types of devices to provide status information to the user (here, lighting devices are "10 lights on", shading devices are "3 shading elements on", and thermostat devices are "currently 72°"). The displayed information and format are examples, and other examples are possible. The compressed / minimized section 620 of interface 1610 can be configured to be scrollable by the user (e.g., from left to right or up / down) to display additional status information, and / or can be configured to display multiple lines of information to the user at once. Alternatively, the compressed / minimized section 620 of interface 1610 may not be scrollable and may display status information for only a subset of the controlled devices. Which devices are displayed may be user-defined or not. When the status of a device changes, the status information shown in the compressed / minimized section 620 of interface 1610 can be dynamically / actively updated by the control application. According to one example, the compressed / minimized section 620 of interface 1610 can be configured to allow the user to select various parts (e.g., "10 lights on", "3 shades on", and "current 72°"), thereby leading the user to a subsequent user interface, as described above. According to another example, the compressed / minimized section 620 of interface 1610 can be configured such that, in response to the user selecting section 620, the section can be re-expanded by a control application and section 660 can be collapsed by a control application, thereby returning to, for example,... Figure 8A The configuration shown. Segment 620 can then be configured to allow the user to select the icon to display, as described above. See also... Figure 8D Assuming an additional pane exists, continuing to scroll "down" on segment 660 can cause the pane at the top of the segment (here, the "Kitchen" pane 1682) to disappear from segment 660, and the additional pane to appear at the bottom of segment 660 (below the "Master Bedroom" pane 1686). Similarly, when segment 660 is scrolled "up" in the opposite direction (to possibly display a pane, such as pane 1682 that may have scrolled out of segment 660), the pane at the bottom of segment 660 can disappear from segment 660 (e.g., pane 1686), and the additional pane can appear at the top of segment 660. Continuing to scroll "up" (and / or collapsing the panes of segment 660) can cause segment 660 to be collapsed by the control application when it reaches the top pane (here, the "Kitchen" pane 1682), and segment 620 will unfold again, and interface 1610 will reappear, as shown in example. Figure 8A As shown. According to another example, as a supplement and / or alternative to the above, in Figure 8A (and similarly) Figure 8BSelecting device tab 642 in the configuration (e.g., by "touch" or "tap") allows segment 660 to be expanded by the control application and segment 620 to be collapsed by the control application, as shown below. Figure 8D As shown. Similarly, segment 660 can then be scrollable. Likewise, in Figure 8D Selecting device label 642 and / or segment 620 in the configuration (e.g., by "touching" or "tapping") will cause segment 660 to fold and segment 620 to unfold again, as shown. Figure 8A (and similarly) Figure 8B As shown in the configuration. Therefore, the expansion and collapse of segments 620 and 660 can be achieved / obtained in various ways, including by scrolling and / or by selecting segment 620 and / or device label 642. Similarly, scene label 644 and timetable label 646 can operate in a similar manner.
[0202] Refer again Figure 8C And segments 662 and 660, this configuration (where segment 660 is not initially shown) can be similar to the above for segments 662 and 660. Figure 8A Operate as described. As an example, using device label 642 as the activation label, interface 1610 is selected, for example, in the area below segment 640 (i.e., possibly segment 660), and segment 660 appears, for example, by "swiping" upwards (but other mechanisms may also be used). Segment 620 disappears from and / or moves out of the network device's display interface by controlling the application to scroll out of and / or move out of the network device's display interface, and segment 660 occupies this space. Alternatively, and as... Figure 8D As shown and as described above, with the appearance of segment 660, segment 620 can be compressed or minimized. Then, Figure 8DThe configuration can be performed as described above. For example, the compressed / minimized section 620 of interface 1610 can be configured to be scrollable by the user (e.g., from left to right or up / down) to display additional status information, and / or can be configured to display multiple lines of information to the user at once. Alternatively, the compressed / minimized section 620 of interface 1610 may not be scrollable and may display status information for only a subset of the controlled devices. Which devices are displayed may or may not be user-defined. When the status of a device changes, the status information shown in the compressed / minimized section 620 of interface 1610 can be dynamically / actively updated by the control application. According to one example, the compressed / minimized section 620 of interface 1610 can be configured to allow the user to select various sections (e.g., “10 lights on”, “3 shades on”, and “current 72°”) via the control application, thereby leading the user to a subsequent user interface as described above. According to another example, the compressed / minimized section 620 of interface 1610 can be configured such that, in response to a user selection of section 620, the section can be re-expanded, and the section 660 can scroll out of the display interface and / or disappear from and / or move out of the display interface, thereby returning to, for example, Figure 8D The configuration shown. Segment 620 can then be configured to allow the user to select the icon to display, as described above. See also... Figure 8D As described above, segment 660 can scroll up and down. Similarly, continuing to scroll "up" (and / or collapsing the pane of segment 660) can cause segment 660 to scroll out of the display and / or disappear from and / or move out of the display when it reaches the top pane (here, the "kitchen" pane 1682), and segment 620 will unfold again, and interface 1610 will reappear, as shown, for example. Figure 8D As shown. According to another example, as a supplement and / or alternative to the above, in Figure 8C Selecting device label 642 in the configuration (e.g., by "touching" or "tapping") can cause section 660 to expand and section 620 to fold, as... Figure 8D As shown. Similarly, segment 660 can also subsequently be scrollable. Likewise, in Figure 8D Selecting device label 642 and / or segment 620 in the configuration (e.g., by "touch" or "tap") causes segment 660 to scroll out of and / or disappear from the display interface and / or be moved out, and segment 620 to re-expand, as shown. Figure 8C As shown in the configuration. Therefore, the expansion and collapse of segments 620 and 660 can be achieved / obtained in various ways, including by scrolling and / or sliding actions and / or by selecting segment 620 and / or device label 642. Similarly, scene label 644 and timetable label 646 can operate in a similar manner.
[0203] Similarly, as discussed herein, status section 620 can provide the user with a summary of the load control system 210a, and corresponding icons can provide the user with access to control devices that the user is more likely to want to control compared to other devices.
[0204] Now for reference Figure 9A Another example graphical user interface 1710 is shown, which can be displayed to a user by a control application via a network device 680. Interface 1710 can be similar to, for example... Figures 8A to 8D Interface 1610 shown herein, as well as other interfaces discussed herein, can operate similarly to interface 1610. Interface 1710 includes another instance of how the control application can instruct the user controlling the application on the use of the device. It should be recognized that, regarding Figure 9A (and similarly) Figures 9B to 9G The display and manipulation of the occupancy discussed herein can be similarly applied to other graphical user interfaces discussed herein.
[0205] In order to describe Figures 9A to 9G Assuming the user environment 202a of the load control system 210a includes four rooms, including a "kitchen", "living room", "master bedroom" and "first-floor bathroom", as follows: Figure 9A Section 660 of interface 1710 is shown. It will also be assumed that the load control system 210a includes at least one or more lighting controls / lamp for each room, and further includes at least one occupancy sensor located in the "living room," at least one occupancy sensor located in the "master bedroom," and at least one occupancy sensor located in the "first-floor bathroom." Each of these rooms in the load control system 202a may include other controls. According to this example, the load control system 210a can be configured such that, for example, one or more lighting controls / lamp in each room can respond to an occupancy and / or idle signal generated by a corresponding occupancy sensor located in said room (but other controls may also respond to occupancy and / or idle signals). The occupancy sensor can be a standalone device, or it can be integrated with or as part of the lighting control device (or other control device). Figure 9AFor example, when the occupancy sensor detects an occupancy event / situation in a room, the control application can receive an indication of the occupancy event from the system controller 250a and display an indication / symbol (e.g., an icon) of this event to the user via the interface 1710. In this way, if the user is notified via the interface 1710, for example, that one or more lighting controls (or other controls) in a room have turned on their respective lighting loads, the user can further see that the room is occupied and therefore can decide not to turn off or change (e.g., dim) the lighting loads in said room through the control application (or, for example, by changing other controls). According to another aspect of this example, when the occupancy sensor detects an vacancy event / situation, the control application can receive an indication of an vacancy event from the system controller 250a and can remove the occupancy indication / symbol from the graphical user interface 1710. Figure 9A On another front, when the control application is initially launched, it can receive the status of the occupancy sensor (e.g., occupied / unoccupied) from the system controller 250a and display an occupancy indicator accordingly. The phrases "vacant / idle" and "unoccupied" are used interchangeably herein. Although the description pertains to the occupancy sensor for controlling lighting control devices... Figures 9A to 9G These are examples, but they can also be applied to controlling other types of control devices, such as occupancy sensors for fans, shades, thermostats, and audio controls mentioned above.
[0206] Now turning more closely Figure 9A The graphical user interface 1710 may include three sections or panes, including a status section 620 as discussed similarly herein, a menu selection / tab section 640, and an information section 660. According to this example and as discussed similarly above, section 620 of interface 1710 may include one or more icons indicating different status information for one or more control devices 220a within the load control system 210a. Here, a lighting device icon 1722 is shown, but as discussed herein, other or additional icons may be shown. According to this example, lighting device icon 1722 indicates that six (6) lighting control devices within the load control system have the corresponding lighting load currently on. As discussed similarly above and below, lighting device icon 1722 may be selected by the user, thereby leading the user to a subsequent user interface. Similarly, when the status of the lighting control devices within the load control system changes, the status information associated with lighting device icon 1722 (e.g., "6 lights on") may be dynamically / actively updated by the control application.
[0207] like Figure 9AAs shown, device label 642 is activated (as indicated by underline 643), thus subdividing section 660 into four panes 1782, 1784, 1786, and 1788, each pane representing a location within user environment 202a (here, "kitchen," "living room," "master bedroom," and "first-floor bathroom" are each represented by one). In this example, each of panes 1782, 1784, 1786, and 1788 is shown in a collapsed state and can be expanded upon the control application detecting that the user has activated / selected the corresponding umbrella label 808. Specifically, upon detecting / determining that the user has activated / selected umbrella label 808, the control application can expand the corresponding pane to display one or more icons representing the control device in the corresponding location, as described herein. According to this example, since an occupancy event is detected by an occupancy sensor in a given room, the control application can receive an indication of the occupancy event from system controller 250a and display occupancy indicators 1724a, 1724b (e.g., icons representing people here, but other icons may also be used) to the user in the corresponding pane of section 660. In this example, the occupancy sensor in the living room has detected an occupancy event, therefore, the control application displays an occupancy indicator 1724a in the living room pane 1784 to indicate that the room is occupied. Similarly, the occupancy sensor in the first-floor bathroom has detected an occupancy event, therefore, the control application displays an indicator 1724b in the first-floor bathroom pane 1788 to indicate that the room is occupied. In this example, the occupancy sensor in the master bedroom has not detected an occupancy event (e.g., detecting vacancy / is vacant), therefore, the control application does not display an occupancy indicator in the "Master Bedroom" pane 1786 to indicate that the room is vacant. In this example, the kitchen does not include an occupancy sensor, therefore, regardless of whether the kitchen is occupied, no occupancy indicator is shown in the kitchen pane 1782. When the control application is initially launched, it can display the occupancy / vacancy status of each room based on status information received from the system controller 250a. When the occupancy / vacancy status of a given room changes, the control application can receive an indication of this change from the system controller and update section 660 to display or remove the corresponding occupancy indicator 1724a, 1724b as appropriate.
[0208] It should be recognized that this is an example. Other than... Figure 9AThe icons other than the "person" icons 1724a and 1724b shown are used to indicate occupancy. Similarly, occupancy indicators 1724a and 1724b can be located outside the right corner of the pane. Similarly, occupancy indicators other than icons can be used to indicate occupancy. For example, an occupancy indicator may include controls for the application to change the background color and / or font used with respect to panes 1784 or 1788 to indicate occupancy. Similarly, instead of providing an indicator to indicate occupancy without providing an indicator to indicate vacancy, an indicator to indicate vacancy (e.g., an vacancy indicator, which may be, for example, an icon) can be used without providing an indicator to indicate occupancy. As another example, one indicator can be used to indicate occupancy (occupancy indicator), and another different indicator can be used to indicate vacancy (vacancy indicator), etc. Furthermore, for rooms such as kitchens that may not have occupancy sensors, the control application can display an indicator (e.g., an icon) in the corresponding pane (here, pane 1782) indicating that the room has no sensors. Therefore, in response to not seeing an occupancy indicator such as indicators 1724a and 1724b, the user will not assume the room is vacant. Other examples are also possible.
[0209] As described above, after detecting / determining that the user has activated / selected the umbrella icon 808, the control application can expand a pane to display icons representing the control devices in the corresponding room. For example, turning... Figure 9BAn example of a living room pane 1784, for instance, is shown, unfolded due to the control application detecting the execution of the pane's umbrella-shaped marker 808. In this example, as similarly described above, two icons 1732a and 1732b representing two lighting controls are shown. These two icons indicate that one or more lighting loads corresponding to the respective lighting controls are in an on state. Further as shown in this example, pane 1784 also includes an icon 1732c representing an occupancy sensor located in the living room. The control application can furthe...
Claims
1. A method for communicating with and controlling a lighting control device, comprising: Information is received from the communication network by at least one processor via the communication circuit. The information mentioned is associated with control devices located within the environment. The control device includes lighting control devices, each configured to control a corresponding lighting load located within the environment. The control device further includes an occupancy sensor, and The occupancy sensor and at least one of the lighting control devices are located within the environment. The at least one processor determines the number of lighting control devices whose corresponding lighting loads are in the on state based on the received information; The at least one processor displays a first graphical user interface on a display screen, the first graphical user interface including a first segment and a second segment, wherein the first segment includes a lighting device icon representing a lighting control device, and wherein the second segment includes a pane presenting the location of the environment; The at least one processor displays a value in the first section corresponding to the determined number of lighting control devices whose corresponding lighting loads are in the on state, via the lighting device icon; The at least one processor determines, based on the received information, that the occupancy sensor has detected an occupancy event indicating that the location is occupied; as well as Based at least in part on determining that the occupancy sensor has detected an occupancy event indicating that the location is occupied, the at least one processor displays an occupancy indicator indicating to the user that the location is occupied within the pane of the second segment.
2. The method of claim 1, further comprising: The at least one processor receives information indicating that the occupancy sensor has detected an vacancy event indicating that the location is vacant; as well as The at least one processor updates the pane of the second segment to indicate to the user that the location is vacant, based at least in part on the vacancy event detected by the occupancy sensor indicating that the location is vacant.
3. The method of claim 2, wherein updating the pane of the second segment to indicate that the position is vacant comprises: The pane in the second section is displayed when the occupancy indicator is not present.
4. The method of claim 2, wherein updating the pane of the second segment to indicate that the position is vacant comprises: In the pane of the second section, an vacancy indicator is displayed to indicate to the user that the location is vacant.
5. The method of claim 1, further comprising: The at least one processor displays an icon corresponding to the at least one lighting control device and an icon corresponding to the occupancy sensor in the pane of the second section.
6. The method of claim 5, further comprising: The at least one processor displays the appearance of the icon corresponding to the at least one lighting control device to indicate that the at least one lighting control device has its corresponding lighting load in the on state.
7. The method of claim 6, further comprising: The at least one processor receives information instructing the at least one lighting control device to turn off its corresponding lighting load; In response to the information instructing the at least one lighting control device to put its corresponding lighting load in the off state, the at least one processor displays a reduced value corresponding to the number of lighting control devices whose corresponding lighting loads are in the on state via the lighting device icon; as well as The at least one processor displays the appearance of the icon corresponding to the at least one lighting control device to indicate that the at least one lighting control device has its corresponding lighting load in the off state.
8. The method of claim 7, further comprising: The at least one processor receives information indicating that the occupancy sensor has detected an vacancy event indicating that the location is vacant; as well as The at least one processor updates the pane of the second segment to indicate to the user that the location is vacant, based at least in part on the vacancy event detected by the occupancy sensor indicating that the location is vacant.
9. The method as described in claim 5, The icon corresponding to the at least one lighting control device can be selected by the user; and The method further includes: The selection of the icon corresponding to the at least one lighting control device is detected by the at least one processor; In response to detecting the selection of the icon corresponding to the at least one lighting control device, the at least one processor displays a control interface on the display screen to control the at least one lighting control device, wherein the control interface includes an actuator; The execution of the actuator is determined by the at least one processor; and In response to determining the execution of the actuator, the at least one processor transmits one or more messages via the communication circuit to control the at least one lighting control device.
10. The method as described in claim 5, The icon corresponding to the occupancy sensor can be selected by the user; and The method further includes: The selection of the icon corresponding to the occupancy sensor is detected by the at least one processor; At least in part in response to the detection of the selection of the icon corresponding to the occupancy sensor, the at least one processor displays a control interface on the display screen to configure how the at least one lighting control device responds to an vacancy event detected by the occupancy sensor and the occupancy event, the vacancy event indicating that the position is vacant; and In part, in response to configuration settings received from the user via the control interface, the at least one processor transmits the configuration settings via the communication circuit to reconfigure how the at least one lighting control device responds to the occupancy event and the vacancy event detected by the occupancy sensor.
11. The method as described in claim 1, The lighting device icon can be selected by the user; and The method further includes: The selection of the lighting device icon is detected by the at least one processor; In response to detecting the selection of the lighting device icon, the at least one processor displays a second graphical user interface to the user on the display screen, and further displays within the second graphical user interface: The numerical value corresponding to the determined number of lighting device icons and lighting control devices whose corresponding lighting loads are in the on state; The icon corresponding to the at least one lighting control device; and An occupancy indicator, together with the icon corresponding to the at least one lighting control device, is used to indicate to the user that the location is occupied.
12. The method of claim 11, further comprising: The at least one processor receives information instructing the at least one lighting control device to turn off its corresponding lighting load; In response to the information instructing the at least one lighting control device to put its corresponding lighting load in the off state, the at least one processor displays a reduced value corresponding to the number of lighting control devices with their corresponding lighting loads in the on state via the lighting device icon in the second graphical user interface; as well as The at least one processor removes the icon corresponding to the at least one lighting control device from the second graphical user interface.
13. The method of claim 11, further comprising: The at least one processor receives information indicating that the occupancy sensor has detected an vacancy event indicating that the location is vacant; as well as The second graphical user interface is updated by the at least one processor, at least in part, based on the occupancy sensor detecting an vacancy event indicating that the location is vacant, to display the icon corresponding to the at least one lighting control device in the absence of the occupancy indicator.
14. A method for communicating with and controlling a lighting control device, comprising: Information is received from the communication network by at least one processor via a communication circuit. This information is associated with control devices located within the environment. The control device includes lighting control devices, each configured to control a corresponding lighting load located within the environment. The control device further includes a first occupancy sensor and a second occupancy sensor. The first occupancy sensor and the first plurality of lighting control devices in the lighting control device are located within a first position in the environment, and The second occupancy sensor and the second plurality of lighting control devices in the lighting control device are located in a second location in the environment; The at least one processor determines, based on the received information, whether each of the first plurality of lighting control devices puts its corresponding lighting load in an on state or an off state, and whether each of the second plurality of lighting control devices puts its corresponding lighting load in an on state or an off state; The at least one processor determines, based on the received information, that the first occupancy sensor has detected an occupancy event indicating that the first position is occupied, and the second occupancy sensor has detected an vacancy event indicating that the second position is not occupied; The at least one processor displays a graphical user interface on the display screen, the graphical user interface comprising: The corresponding icon of each lighting control device whose corresponding lighting load is in the on state in the first plurality of lighting control devices in the first position, together with the corresponding icon of each lighting control device whose corresponding lighting load is in the on state in the second plurality of lighting control devices in the second position; Based at least in part on determining that the first occupancy sensor has detected an occupancy event indicating that the first location is occupied, the at least one processor displays a corresponding occupancy indicator within the graphical user interface for each corresponding icon of each of the first plurality of lighting control devices whose corresponding lighting load is in an on state, wherein the corresponding occupancy indicator indicates to the user that the first location is occupied; and Based at least in part on determining that the second occupancy sensor detects an vacancy event indicating that the second position is not occupied, the at least one processor displays, within the graphical user interface, each corresponding icon of each of the second plurality of lighting control devices whose corresponding lighting load is in the on state, by indicating to the user that the second position is not occupied.
15. The method as described in claim 14, The method further includes: The at least one processor detects within the graphical user interface the selection of an icon corresponding to one of the first plurality of lighting control devices whose respective lighting load is in the on state. In response to detecting the selection of an icon for one of the lighting control devices corresponding to the one lighting load of the first plurality of lighting control devices being in an on state, at least one processor displays a control interface on a display screen to control the one lighting control device, wherein the control interface includes an actuator; The execution of the actuator is determined by the at least one processor; as well as In response to determining the execution of the actuator, the at least one processor transmits one or more messages via the communication circuit to control the lighting control device.
16. The method of claim 15, further comprising: At least in part, based on the transmission of the one or more messages, the at least one processor receives information instructing the lighting control device to turn off its corresponding lighting load; as well as In response to the information instructing the lighting control device to put its corresponding lighting load in the off state, the at least one processor clears the icon corresponding to the lighting control device from the graphical user interface to instruct the lighting control device to put its corresponding lighting load in the off state.
17. The method of claim 14, wherein displaying each corresponding icon of each lighting control device corresponding to its corresponding lighting load being in an on state in a manner that indicates to the user that the second position is not occupied includes displaying each corresponding icon corresponding to an unoccupied indicator for each of the second plurality of lighting control devices.
18. The method of claim 14, further comprising: The at least one processor receives information indicating that the first occupancy sensor has detected an vacancy event indicating that the first location is not occupied; as well as Based at least in part on information indicating that the first occupancy sensor detected an vacancy event indicating that the first location was not occupied, the at least one processor updates the graphical user interface to clear the corresponding occupancy indicator from each corresponding icon of each of the first plurality of lighting control devices whose corresponding lighting load is on, in order to indicate to the user that the first location is not occupied.
Citation Information
Patent Citations
Light Control Apparatus and Method of Controlling Light Thereof
CN105451412A