Method for integrating plug load controller in lighting system

Abstract

A distributed control system comprises a plurality of controllers, each of the plurality of controllers communicating with the remaining controllers of the plurality of controllers, each controller being configured to control at least one device, and each controller being further configured to: in response to a received signal, start a first timer having a length that is unique relative to the length of the first timers of the remaining controllers of the plurality of controllers; send a first notification signal to the remaining controllers when the first timer expires, the first notification signal notifying the remaining controllers of the intention to send a command signal; and send a command signal to at least one device, wherein the controller is configured to: cancel sending the notification signal and the command signal if a notification signal is first received from one of the remaining controllers of the plurality of controllers before the first timer expires.

Description

Technical Field

[0001] The present invention is directed to distributed control systems. More specifically, various inventive methods and apparatus disclosed herein relate to a distributed control system comprising a plurality of distributed controllers configured to control at least one slave device in a coordinated manner. Background Art

[0002] To further improve building energy efficiency, intelligent control of plug-in devices is becoming a key consideration in building codes such as Title 24 (2013) and ASHARE 90.1 (2010). Plug load control improves energy efficiency by automatically disconnecting power to designated plug loads when a space is vacated. In commercial buildings, unused or standby products account for 25% of total electricity consumption. Examples include task lighting, computers, monitors, cell phone chargers, A / V equipment, and other electronic devices, which can be shut down without harmful consequences when occupants are not nearby or at appropriate times (for example, at night).

[0003] Since plug load control is primarily related to the presence of an individual, it can in principle be combined with lighting control systems that are also based on occupancy information or schedules. Therefore, in addition to intelligent lighting control, many lighting companies have begun to offer plug load control.

[0004] For new construction or complete renovations, appropriate networked power controllers can be installed and cables can be run to the desired plug sockets to control them. As an example, the Philips Dynalite system offers load controllers controlled via the DyNet protocol to operate devices such as curtains and blinds in addition to lighting. Other approaches include direct sensor control of plug load sockets using wired or wireless interfaces.

[0005] Many systems used to control plug-load systems have inherent problems. For example, a single central controller used to control a plug-load system can become a single point of failure, either due to a malfunction, a user's incorrect disconnection, or due to an overload of messages from the single central controller that needs to be processed. This is especially true if the central controller manages both lighting and plug-load control for a larger network (e.g., a floor or branch building).

[0006] In addition, there is a special requirement for the gateway to actively listen to sensor data from designated areas and generate plug load control commands accordingly in real time, which may lead to increased network traffic because the sensors in each luminaire may need to report to the central controller in addition to reporting to the local lighting group.

[0007] In extreme cases, a dedicated central controller with occupancy sensors separate from the sensors integrated into the luminaires might be sufficient to meet building codes; however, this is suboptimal because it increases the overall cost due to the duplication of occupancy sensors and installation processes. Additionally, having a dedicated gateway is often unacceptable for other reasons, such as the installation cost of placing and powering the gateway, finding a logical location for the gateway in an otherwise enclosed ceiling, etc.

[0008] Therefore, there is a need in the art for a distributed control system with low network overhead for controlling plug load control devices or other similar slave devices. Summary of the Invention

[0009] This disclosure describes various embodiments of a distributed control system comprising multiple distributed controllers configured to control at least one slave device in a coordinated manner, thereby creating a many-to-one or many-to-many relationship between the controller and the slave devices in a low-network-overhead configuration. In view of the foregoing, various embodiments and implementations are directed to a control system comprising multiple distributed controllers, each of which is configured to notify the remaining distributed controllers of its intent to control at least one slave device. Thus, each controller is aware of the future state of the slave device and the actions to be taken by the remaining distributed controllers.

[0010] Generally, in one aspect, a distributed control system includes: a plurality of controllers, each of the plurality of controllers communicating with the remaining controllers of the plurality of controllers, each controller being configured to control at least one device, each controller being further configured to: start a first timer in response to a received signal, the first timer having a length that is unique relative to the length of the first timers of the remaining controllers of the plurality of controllers; send a first notification signal to the remaining controllers when the first timer expires, the first notification signal notifying the remaining controllers of the intention to send a command signal; and send a command signal to at least one device, wherein the controller is configured to: cancel sending the first notification signal and the command signal if the first notification signal is received from one of the remaining controllers of the plurality of controllers before the first timer expires.

[0011] According to one embodiment, each controller is further configured to: start a second timer, which expires after the first timer expires, and the second timer has a length that is unique relative to the second timer length of the remaining controllers in the multiple controllers; when the second timer expires, send a second notification signal to the remaining controllers, and the second notification signal notifies the remaining controllers of the intention to send the second command signal; and send the second command signal to at least one device, wherein the controller is configured to: cancel sending the second notification signal and the second command signal if the second notification signal is received from one of the remaining controllers in the multiple controllers before the second timer expires.

[0012] According to one embodiment, each controller is further configured to:

[0013] A third timer is started, wherein a length of the third timer is the same across all remaining controllers and is longer than a length of the first timer; and in response to expiration of the third timer, a second timer is started.

[0014] According to one embodiment, at least one device is a plug load control device.

[0015] According to one embodiment, the first command signal is an on command configured to cause the plug load control device to cause power to be delivered to the outlet.

[0016] According to one embodiment, the received signal is a sensor signal.

[0017] According to one embodiment, the received signal is received only at a subset of the plurality of controllers, wherein the notification signal notifies at least one of the remaining controllers of the detected motion.

[0018] According to one embodiment, the sensor signal is generated at a sensor that is coupled to at least one controller of the plurality of controllers.

[0019] According to one embodiment, a controller coupled to a sensor is configured to communicate the sensor signal to the remaining distributed controllers.

[0020] According to one embodiment, the received signal is received from another controller among the plurality of controllers.

[0021] According to one embodiment, the second command signal is a shutdown command.

[0022] According to one embodiment, the length of the first timer is randomly set and has a maximum possible value.

[0023] According to one embodiment, each controller includes a corresponding wireless module through which each controller communicates with the remaining controllers of the plurality of controllers.

[0024] In another aspect, a distributed control system includes a plurality of controllers, each controller in the plurality of controllers communicating with the remaining controllers in the plurality of controllers, each controller configured to control at least one device, each controller further configured to:

[0025] In response to the received signal, a command signal is sent to the remaining controllers and the at least one device, wherein the remaining controllers and the at least one device recall pre-stored settings in response to the command signal.

[0026] According to one embodiment, each controller is further configured to:

[0027] A timer is started, the second timer having a length that is unique relative to the second timer lengths of the remaining controllers in the plurality of controllers; a second command signal is sent to the remaining controllers and the at least one device, wherein the remaining controllers and the at least one device recall the second pre-stored setting in response to the second command signal.

[0028] In various embodiments, a processor or controller may be associated with one or more storage media (collectively referred to herein as "memory," e.g., volatile computer memory and non-volatile computer memory, such as RAM, PROM, EPROM, and EEPROM, floppy disks, compact disks, optical disks, magnetic tape, etc.). In some embodiments, the storage media may be encoded with one or more programs that, when executed on one or more processors and / or controllers, perform at least some of the functions discussed herein. The various storage media may be fixed within the processor or controller, or may be removable such that one or more programs stored thereon can be loaded into the processor or controller in order to implement various aspects of the invention discussed herein. The terms "program" or "computer program" are used herein in a generic sense to refer to any type of computer code (e.g., software or microcode) that can be used to program one or more processors or controllers.

[0029] In one network embodiment, one or more devices connected to the network may act as controllers for one or more other devices coupled to the network (e.g., in a master / slave relationship). In another embodiment, a networked environment may include one or more dedicated controllers configured to control one or more of the devices coupled to the network. Generally, each of the multiple devices coupled to the network can access data present on a communication medium or media; however, a given device may be "addressable" in that it is configured to selectively exchange data with the network (i.e., receive data from the network and / or send data to the network), for example, based on one or more specific identifiers (e.g., "addresses") assigned to it.

[0030] As used herein, the term "network" refers to any interconnection of two or more devices (including controllers or processors) that facilitates the transmission of information (e.g., for device control, data storage, data exchange, etc.) between any two or more devices and / or between multiple devices coupled to the network. As should be readily understood, various embodiments of networks suitable for interconnecting multiple devices may include any of a variety of network topologies and employ any of a variety of communication protocols. Furthermore, in various networks according to the present disclosure, any one connection between two devices may represent a dedicated connection between the two systems, or alternatively, a non-dedicated connection. In addition to carrying information intended for the two devices, such a non-dedicated connection may also carry information that is not necessarily intended for either of the two devices (e.g., an open network connection). Furthermore, it should be readily understood that the various device networks discussed herein may employ one or more wireless, wired / cable, and / or fiber optic links to facilitate information transmission throughout the network.

[0031] It should be understood that all combinations of the aforementioned concepts and the additional concepts discussed in more detail below (provided such concepts are not mutually inconsistent) are considered part of the inventive subject matter disclosed herein. In particular, all combinations of the claimed subject matter appearing at the end of this disclosure are considered part of the inventive subject matter disclosed herein. It should also be understood that terminology that is explicitly employed herein and that also may be incorporated by reference and that appears in any disclosure should be given a meaning most consistent with the specific concepts disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In the drawings, like reference numerals generally refer to the same components throughout the different views. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention.

[0033] Figure 1 is a schematic representation of a distributed control system according to one embodiment.

[0034] Figure 2A is a schematic representation of a distributed controller according to one embodiment.

[0035] Figure 2B is a schematic representation of a slave device according to one embodiment.

[0036] Figure 3 is a schematic representation of a distributed control system according to one embodiment.

[0037] Figure 4 is a flow chart of a method implemented by a distributed controller according to one embodiment.

[0038] Figure 5 is a flow chart of a method implemented by a distributed controller according to one embodiment.

[0039] Figure 6A is a message sequence chart of a distributed control system according to one embodiment.

[0040] Figure 6B is a message sequence chart of a distributed control system according to one embodiment.

[0041] Figure 7A is a message sequence chart of a distributed control system according to one embodiment.

[0042] Figure 7B is a message sequence chart of a distributed control system according to one embodiment.

[0043] Figure 8A is a message sequence chart of a distributed control system according to one embodiment.

[0044] Figure 8B is a message sequence chart of a distributed control system according to one embodiment. DETAILED DESCRIPTION

[0045] The present disclosure describes various embodiments of a distributed control system including a plurality of distributed controllers configured to control at least one slave device in a coordinated manner, thereby creating a many-to-one or many-to-many relationship between the controllers and the slave devices.

[0046] In view of the foregoing, various embodiments and implementations are directed to a control system comprising a plurality of distributed controllers, each of which is configured to notify the remaining distributed controllers of its intent to control at least one slave device. Thus, each controller is aware of the future state of the slave device and the actions to be taken by the remaining distributed controllers.

[0047] Reference Figure 1 In one embodiment, a schematic diagram of a distributed control system 10 is provided. As shown, the distributed control system includes multiple distributed controllers 12 (designated DC) and multiple slave devices 14 (designated SD). In one embodiment, each controller 12 is responsible for controlling each slave device 14. To maintain low network overhead, the distributed controllers 12 control the slave devices 14 in a coordinated manner, such that only one controller 12 sends control signals to each slave device 14.

[0048] According to one embodiment, at a high level, each distributed controller can activate a timer in response to an input (e.g., a sensor input or a user input). The length of the timer for each distributed controller is unique relative to the other distributed controllers. The distributed controller 12 with the shortest timer will notify the remaining distributed controllers 12 of its intention to control the slave device 14 when the timer expires. In response to the notification, the remaining distributed controllers 12 will not attempt to control the slave device 14. The distributed controller 12 that sent the notification will then control the slave device 14 without interference or unnecessary control signals from the remaining distributed controllers, thereby keeping network overhead low. This sequence can be used to activate, deactivate, or otherwise control the slave device 14. This will be discussed below in conjunction with Figures 2A-8B This sequence and other related embodiments are discussed in depth.

[0049] Go to Figure 2A , shows a schematic representation of a distributed controller according to one embodiment. For example, each distributed controller can be included in each luminaire 16 as part of an extension of an existing (or new) distributed lighting control system. In fact, the system described herein can be used with a lighting system that is extended with non-lighting controllers in multiple domains, groups (such as plug loads, HVAC equipment, blinds controllers, etc.). Alternatively, the distributed controller 12 can be an extension of a different control system or implemented as a stand-alone system. In yet another alternative, the distributed controller functionality can be available in a device that is part of a network but is not itself controlled by an input (for example, an energy meter in a building automation system that includes lighting control and HVAC control). The distributed controllers 12 can each include a memory 18 and a processor 20, the memory 18 and the processor 20 being respectively configured to store and execute combined Figure 4-8B Describe the steps.

[0050] The distributed controller may further include a wireless module 22 that facilitates communication (via antenna 24) between the distributed controllers 12, and / or between the distributed controller 12 and the slave devices 14, and / or between the distributed controller 12 and (such as switches 44, independent sensors 46, or gateways 48) Figure 4Wireless communication between any connected devices (collectively shown in the figures). The wireless communication may be ZigBee, Bluetooth, Thread, WiFi, LiFi, or any other visible light communication protocol or any other wireless protocol. In one embodiment, a combination of network types may be used (e.g., one protocol type for communication between distributed controllers 12 and another protocol for communication with slave devices 14, or one protocol type for communication between a sensor (integrated 30 or standalone 46) or switch 44 and a distributed controller 12, and another protocol for communication between the distributed controller 12 and slave devices 14). In yet another embodiment, communication between different device groups / types may use not only different protocols, but also different interfaces. Although the wireless module 22 is shown as an integrated component of the distributed controller 12, the wireless module 22 may be a separate component. For example, the wireless module 22 may be separate from the distributed controller 12 but in wired communication with the distributed controller 12. Wireless module 22 may include memory 26 and processor 28 (which may be memory 18 and processor 20 ) that may be programmed or configured to facilitate and / or implement the functionality of wireless module 22 as described or otherwise contemplated herein.

[0051] In yet another embodiment, the distributed controllers 12 are wired together and / or to the slave devices 14 and / or to any peripheral devices such as switches or gateways, rather than communicating wirelessly.

[0052] Each distributed controller 12 may further include a sensor 30, such as an occupancy sensor, to determine the presence of a user within a predetermined area (e.g., a room). The occupancy sensor may use at least one of the following sensing modalities, or a combination thereof: passive infrared, ultrasound, microwave, radar, cameras of any resolution and spectrum, including thermal imaging and electromagnetic signal perturbations. The sensor 30 may be integrated into at least one of the distributed controllers 12, or may be a stand-alone sensor 46 (e.g., a sensor) that communicates with at least one of the distributed controllers 12. Figure 4 ).

[0053] The slave device 14 may be, for example, a lighting device or a plug load control device, however, it should be understood that other types of slave devices may be used. Similar to the distributed controller 12, the slave device 14 may include a memory 32 and a processor 34, each of which is configured to store and execute the combined Figure 4-8B Describe the steps.

[0054] Each slave device 14 may further include a wireless module 36 that facilitates wireless communication between the distributed controller 12 and the slave device 14 (via an antenna 38). The wireless communication may be ZigBee, Bluetooth, Thread, WiFi, LiFi, or any other visible light communication protocol or any other wireless protocol. In one embodiment, a combination of network types may be used (e.g., one protocol type for communication between the distributed controllers 12 and another protocol for communication with the slave devices 14). While the wireless module 36 is shown as an integrated component of the slave device 14, the wireless module 36 may be a separate component. For example, the wireless module 36 may be separate from the slave device 14 but in wired communication with the slave device 14. The wireless module 22 may include a memory 40 and a processor 42 (which may be the same as the memory 32 and processor 34). The memory 40 and processor 42 may be programmed or configured to facilitate and / or implement the functionality of the wireless module 22 as described or otherwise contemplated herein.

[0055] In one embodiment, the distributed controllers 12 may be divided into one or more groups. Figure 4 As shown in FIG, the distributed controllers are divided into two groups, in which one set of slave devices 14 is controlled by one group (e.g., Group 1) and the other set of slave devices 14 is controlled by the other group (e.g., Group 2). In other words, all distributed controllers in a given group are responsible for controlling all slave devices 14 in the same group. The groups of slave devices 14 and the corresponding sets can be formed during the network initialization phase or can be configured later by the user.

[0056] In addition to receiving input from sensors 30, distributed controller 12 can receive input from other input devices, such as switches 44 for manually overriding lighting controls and stand-alone sensors 46 (e.g., for improved coverage of specific detection zones). Furthermore, distributed controller 12 can be connected to a gateway 48 (i.e., a networked controller), such as an on-premise building management system or a cloud-based service. Such a networked controller can be used to facilitate network initialization or scheduling. Thus, inputs to distributed controller 12 can further include, for example, time signals from gateway 48 that trigger scheduled actions (e.g., shutting down an entire floor at night), or demand response signals from gateway 48 requesting a reduction in energy consumption in a specific room.

[0057] The control behavior for a single distributed controller is given by Figure 4 The method 50 is further explained in the flowchart shown in FIG. Figure 4-8BFor purposes of this disclosure, the activities of one of the distributed controllers 12 will be described. Although the activities are described in conjunction with a single controller 12, the activities and programming of each controller 12 are the same or substantially the same and, therefore, may be implemented by any of the controllers 12. However, to avoid ambiguity, Figure 4-8B The controller of the focus will be DC i Indicates that other distributed controllers will be DC j≠i express.

[0058] Figure 4 In step 52, the controller 12 (DC i ) can begin with a reset state that clears any configuration data and / or pending actions to place the controller in a predetermined idle state. In an alternative embodiment, if no configuration data or pending actions need to be cleared, step 52 can be skipped to enter the idle period at step 54.

[0059] At step 54, the controller 12 (DC i ) enters an idle waiting period until it receives input. Upon receiving input ( Event: Input )—such as input from sensor 30 (or standalone sensor 46), wall switch 44, or a pre-programmed event—controller 12 (DC i ) activates the command timer. In one embodiment, in response to the input, the controller 12 (DC i ) can also combine messages (such as Figure 6A Sending of description MotionDetectedMessage ) is sent to other distributed controllers 12 (DC j≠i ), notifying them of the input. This may be particularly important if the other distributed controllers do not receive independent notification of the input (which may happen, for example, if the controller 12 receives a signal from an integrated sensor 30). MotionDetectedMessage messages, for example: to align the states of actuators connected to distributed controllers (e.g., to ensure that a light directly controlled by a distributed controller turns on); to increase the number of distributed controllers that can pass messages to slave devices (e.g., if the distributed controller itself is not controlled by an input); and / or to align the states of different distributed controllers. Thus, from other distributed controllers (DC j≠i ) point of view, the input can be from the distributed controller 12 (DC i ) signal.

[0060] The command timer represents the time relative to other distributed controllers 12 (DC j≠i ) only wait period 58. If the timer expires ( Event: Command_TimerTrigger ), then the controller 12 (DC i ) will notify the other distributed controllers (DCs) of its intention to send a command at step 60. j≠i In response, the other distributed controllers 12 (DC j≠i ) will not send a notification or command (i.e., the other distributed controllers will cancel the command - as used herein, canceling the command does not necessarily mean that an operation to send the command is already in progress). i ) sends the notification, it sends the command to the slave device 14 at step 62. If the controller 12 receives a command from another distributed controller 12 (DC j≠i ) of one of the notifications ( Event: NotificationFromOtherController ), then the controller (DC i ) will cancel the notification and command. Controller 12 (DC i ) can further deactivate the command timer at step 64. After deactivating the command timer or sending the command, the controller 12 (DC i ) will enter a reset or idle wait state to await another event. Those skilled in the art will appreciate that method 50 is defined with reference to the task of controlling slave devices; the distributed controller can also perform other tasks in any state of this process (including the idle state), such as sending and receiving other data (e.g., commands required to keep the network operational), performing calculations, etc.

[0061] As described above, each distributed controller 12 will implement a timer that has a relatively unique length relative to the remaining distributed controllers. For example, this can be achieved by each distributed controller 12 implementing a timer with a random length within a range of possible lengths (e.g., having a minimum possible value and a maximum possible value). It will be understood that the random length as used herein can be generated by an algorithm configured to generate pseudo-random values. It should be understood that depending on the size of the set of values ​​to be randomly selected (subject to forwarding delays), and the number of distributed controllers generating random numbers at any given moment, there is a certain probability that two or more distributed controllers 12 will generate the same timer length and / or will send a notification message (or other message depending on the timer / embodiment) at the same time. However, because in many instances a timer based on a random number generator will produce a unique timer length, it should be understood that a random timer is considered a method of generating unique timer lengths among the distributed controllers 12.

[0062] Because each distributed controller 12 is implementing its own timer with a random length, it is unlikely that two controllers will have the same length. Alternatively, each distributed controller can implement a timer with a predetermined length so that the distributed controllers 12 send commands in a predetermined order relative to each other. This order can be determined during a configuration cycle and can be set automatically or by the user. In another embodiment, the timer can be derived based on a received trigger (e.g., the RSSI of a frame received from a stand-alone sensor). In another example, any other value from the trigger signal can be used, such as the sequence number of a frame received from a stand-alone sensor or the handle of a signal received from an integrated sensor. In another example, a unique timer can be generated by combining the received value with the distributed controller's own sequence number. Those skilled in the art will understand that while each distributed controller 12 may need to implement a timer that is unique relative to the rest of the distributed controllers, the manner in which the timer is uniquely set can be accomplished in a variety of ways.

[0063] Figure 5 A flow chart depicting a method 70 of steps implemented by a controller configured to control, for example, a plug load controller or lighting device in conjunction with a motion detector that determines when the plug load controller should be activated is shown. It will be appreciated that the same series of steps can be applied to any other device that should be activated in response to a sensor, switch, or other input and deactivated after a period of no input.

[0064] As in method 50 , at step 70 , the controller 12 (DC i ) starts in a reset state (or, in another embodiment, directly in an idle waiting period), after which, at step 72, the device enters an idle waiting period until it receives input. At step 74, upon receiving a motion detection input from a motion sensor ( Event: MotionDetection ) After that, a set of timers are activated, which at least include the SD ON timer and the SD OFF timeout timer. Figure 5 The timer described is a timer having a j≠i ) is a timer with the unique length of the SD ON timer.

[0065] At step 76, the controller 12 (DC i ) Wait for the SD ON timer to expire or for a message from another distributed controller 12 (DC j≠i ) is notified. If the SD ON timer expires ( Event: SD_ON_TimerTrigger ), then the controller 12 (DC i) in step 78 notifies the other distributed controllers 12 (DC j≠i ), thereafter, at step 80, the controller 12 sends an SD ON command. As a result of receiving the notification, the other distributed controllers 12 (DC j≠i ) will cancel the SD ON command sent to the slave device 14. If the SD ON command is sent from another distributed controller 12 (DC j≠i ) received a notification ( Event: SD_ON_IntentFromOthers ), then the controller 12 (DC i ) can deactivate the SD ON timer and thus cancel sending the SD ON command to the slave device.

[0066] In either case, once (controller 12 (DC i ) or another controller 12 (DC j≠i )) sends the SD ON command to the slave device, then the controller 12 (DC i ) will wait at step 84 for the SD OFF timeout timer to expire (representing a predetermined time when no motion detection signal has been received, suggesting that the predetermined area is now empty), or for a signal from another controller 12 (DC j≠i ) of the slave device 14 has been or will be other controllers (DC j≠i In one embodiment, the length of the SDOFF timeout timer is the same for all distributed controllers—and all slave devices.

[0067] If the controller 12 (DC i ) receives a presence indication while the SD OFF timeout timer is running - the presence indication comes from, for example, a sensor (integrated 30 or standalone 36) or another distributed controller 12 (DC j≠i )——Controller 12 (DC i ) restarts the SD OFF timeout timer. Additionally, in one embodiment, the distributed controller 12 may start the SD ON timer to send another SD ON command to the slave device.

[0068] In another embodiment, the length of the SD OFF timeout timer and / or the SD ON timer and SD OFF timer may vary between distributed controllers depending, for example, on the type of area they control, the number of distributed controllers in the area, typical motion / presence patterns in the area, etc.

[0069] As described above, in one embodiment, each slave device 14 can initiate its own SD OFF timeout timer. In one embodiment, the length of the SD OFF timeout can vary between slave devices 14. The length of the SD OFF timeout timer can depend on the type of slave device 14. For example, for traditional lamps and plugs, the SD OFF timeout timer lengths can vary, with the lamp remaining on longer to allow the user to safely exit the area, while the plug (for example, when powering a computer monitor) is turned off more quickly. Alternatively, the lamp can be turned off quickly, while the plug (for example, when powering a projector) remains on longer to allow the lamp to cool. Furthermore, the length of the SD OFF timeout timer can depend on the relative locations of the switch / sensor, controller 12, and slave devices 14. For example, if the sensor is at the main floor entrance, a plug controlling a task light at the end of the floor (when people are expected to arrive in that area) may be turned on with a higher delay. In yet another embodiment, multiple values ​​for a particular timer can be used for the same area.

[0070] If the SD OFF timeout timer expires ( Event: SD_OFF_TimeoutTrigger ), then the controller 12 (DC i ) activates the SD OFF timer at step 86, which has a relative j≠i ) unique length, which determines which controller will send the SD OFF command to the slave device. However, if the slave device is sent from another controller 12 (DC j≠i ) receives a message from the slave device that has been or will be sent to another controller (DC j≠i ) deactivation notification, the controller 12 (DC i ) will not send the SD OFF command and will start again in reset or idle state.

[0071] Controller 12 (DC i ) Wait for the expiration of the SD OFF timer at step 88. If the SD OFF timer expires ( thing Component: SD_OFFTimerTrigger ), then the controller 12 (DC i ) will notify the other distributed controllers 12 (DC) of its intention to send the SD OFF command to the slave device 14 at step 90. j≠i ). At step 92, the controller 12 (DC i ) sends an SD OFF command to the slave device 14. However, if a command indicating that another controller 12 (DC j≠i ) Notification of intent to send SD OFF command ( Event: SD_OFFIntentFromOthers ), then the controller 12 (DC i) will not send the SD OFF command and will start again in reset or idle state.

[0072] therefore, Figure 5 A system is described that enacts three timers: a first timer for determining which controller 12 will send an ON command to a slave device 14; a timeout timer for determining when a period of time has elapsed sufficient to determine that a person is no longer in the room; and a final timer for determining which controller will send an OFF command. In another embodiment, only two timers may be used by combining the timeout timer and the OFF command timer into a single timer having a length greater than the timeout timer, but still unique to each controller 12 to prevent the controllers from sending redundant OFF signals.

[0073] Go to Figure 6A , combined with Figure 5 The example embodiment of the described method is shown as a state diagram to provide a more global view of the actions taken by each controller 12. In phase 1, by sending a message (send MotionDetectedMessage ), by a distributed controller 12 (DC i ) detected motion (from people entering the room) is communicated with other distributed controllers (DC j≠i ) shared. In phase 2, the room is now occupied and this message triggers a sequence of actions related to the control of the slave devices belonging to the same group. If the state of the distributed controller and / or the plug load is OFF, all distributed controllers (DC j≠i ) (ie with DC i controllers in the same group) will activate a timer corresponding to the interval required to turn off the socket when it is unoccupied ( SD_OFF_Timeout ) and a random interval for backing off from sending socket control commands ( SD_ON_Timer ).

[0074] In some embodiments, all or some of the distributed controllers 12 may not know the status of the slave devices 14 but may estimate the status of the slave devices 14 based on the status of each distributed controller 12 or based on the most recently recorded status.

[0075] First backoff timeout triggers ( SD_ON_TimerTrigger ) of the distributed controller (here is DC i ) will be sent via the message ( NotificationMessage ) to other distributed controllers 12 (DC j≠i ) sends a notification about the intended state of the socket. Thereafter, the Distributed Controller (DC i ) sends a socket control command to all sockets in the group ( SD_ON_Command). This backoff behavior helps keep the network overhead of slave device control low.

[0076] In an alternative embodiment, sensor 30 or sensor 46 may provide a trigger for shutting down slave device 14 by reporting an unoccupied state.

[0077] In phase 3, when a person leaves the room or is replaced by another distributed controller in the same group or by the same controller (DC i ) detects another motion event, it can report the detected motion to other distributed controllers (DCs) after a predefined event registration interval. j≠i Regarding socket control, this event causes the socket switch off interval to be reset ( SD_OFF_Timeout Since all distributed controllers know the socket status (ON), no additional commands need to be sent. This helps further keep network usage low.

[0078] Figure 6B yes Figure 6A and shows the sequence of events when the room is finally identified as vacant by the distributed controller 12. After the SD OFF timeout timer expires ( SD_OFF_TimeoutTrigger ), each distributed controller activates a unique backoff timer ( SD_OFF_Timer ) to ensure that it is the controller that needs to command the slave device to shut down. Ultimately, one of the distributed controllers 12 (here DC i ) will detect the expiration of the backoff timer ( SD_OFF_ TimerTrigger ), and the notification message ( NotificationMessage_SD_OFF ) is sent to other distributed controllers (DC j≠i Upon receiving this message, other distributed controllers (DC j≠i ) deactivates its backoff timer. After sending the notification message, the controller 12 (DC i ) Send the SD OFF command to deactivate the slave device.

[0079] It is worth noting that the distributed controller that sends the SD OFF command does not have to be the controller that activates the slave device 14 - this can be done by any other distributed controller 12.

[0080] In the above embodiment, separate commands are used to control the slave devices and to notify the other distributed controllers. Separate commands may be used for various reasons, including: (1) the two device types support different command sets, precluding the use of the same command; (2) both device types support the same command(s), but the intended application behavior of the two device types when occupancy is detected is different; (3) if the commands for the slave devices are also supported by the distributed light controllers, then within each group, the two device types may need to be separated by using subgroups to allow communication for only one device type.

[0081] In addition, in another embodiment, additional information may be included in the notification message or command, such as additional timing-related information, level, reset information, etc.

[0082] In another embodiment, an acknowledgment message is sent from the controller 12 to confirm that the state change command was sent to the slave device 14, which sends the command to the remaining distributed controllers 12. In one embodiment, the acknowledgment message can be sent as an alternative to or in addition to a message notifying the other distributed controllers of the controller's intention to send a state change command. In another embodiment, the command and acknowledgment messages can be sent by different entities, for example, a distributed controller 12 can send a control command to a slave device 14, and the slave device 14 can notify the other controllers of its state change, for example using a status report. In an extension, the distributed controllers 12 only stop their timers and cancel their scheduled transmission of the state change command when they receive the acknowledgment command. Multiple distributed controllers can send state change commands at their respective timeouts until no acknowledgment is received to increase the probability that the slave device will receive the state change command.

[0083] In another embodiment, the same message is used to communicate with both types of devices; resulting in an even further reduced traffic (eg, notification signals and / or confirmation signals combined with command signals).

[0084] like Figures 7A-7B As shown in FIG, in an alternative embodiment, the motion detection message can also serve as a signal for other distributed controllers 12 (DC j≠i ) notification message role. In this case, if the other distributed controllers 12 (DC j≠i If a controller 12 also receives input indicating motion (e.g., in one embodiment, a subset of all distributed controllers 12), a motion detection message may be sent after a unique backoff period. As shown, after a person enters a room, the controller 12 activates the backoff timer to send a motion detection message (activates the backoff timer). MotionDetected_Timer It should be understood that only some controllers 12 (DC j≠i) (eg, those controllers that receive sensor signals or other signals) will activate the motion detection timer, while the other controllers may remain idle. The first controller 12 (here DC i )( event: MotionDetected_TimerTrigger ) Send motion detection message (send MotionDetected_Message As shown in the figure, the first controller 12 (here DC i ) You can also send the SD ON command. (Alternatively, as Figure 6A As shown in FIG, after sending / receiving a motion detection message, the controller 12 may start an SD ON timer to determine which controller sent the ON command. In other words, the controller 12 that sends the motion detection message is not necessarily the same as the controller 12 that sends the SD ON command. j≠i )take over MotionDetected The message causes those distributed controllers to cancel any scheduled MotionDetected Message (to MotionDetected_Timer Deactivate) - This step applies to the distributed controllers 12 that have previously received an input indicating motion. Finally, all distributed controllers 12 in the group (regardless of whether they initially received a signal indicating detected motion) start the SD OFF timeout timer (activate) in response to the motion detection message. SD_OFF_Timeout ). Figures 7A-7B The rest of the components are combined with Figures 6A-6B The elements described are the same or substantially similar and therefore require no further discussion here.

[0085] like Figures 8A-8B As shown in , in an alternative embodiment, the slave devices 14 and / or the distributed controller 12 can be configured to store recallable configurations (i.e., scenes) that can be recalled using commands from the controller. The presets for a given event can be coordinated and different among all the slave devices 14 in the group. (For example, under a first preset command, when occupancy is detected, the lights in the hallway and window side can go to different light levels.) Thus, by sending a given command (e.g., Recall_SCENE_1 ), the controller 12 that detects motion can let all other distributed controllers 12 and slave devices 14 in the same group know that motion has been detected and therefore have them take appropriate pre-configured actions.

[0086] In this case, network traffic may be further reduced because no explicit message and command transmission is required—only the predefined recall command is needed. Figure 8A As shown in the state diagram in FIG, at the end of phase 1, the controller 23 (DC i ) detects motion and sends it to other distributed controllers (DCj≠i ) and the slave device sends commands ( Recall_SCENE_ 1 In response to ( Recall_SCENE_1 ) command, the slave device 14 takes a preconfigured action. In the case of a plug load controller, the preconfigured action may be to activate the plug load controller relay to provide power to the outlet. The distributed controller 12 (DC j≠i ) activate their SD OFF timeout timer (activate SD_OFF_Timeout ). Controller 12 (DC i ) also activates its SD OFF timeout timer (activates SD_OFF_Timeout In one embodiment, as described above, scenario 1 stored in the slave device 14 may include setting the SD OFF timeout timer, rather than implementing the SD OFF timeout timer in the distributed controller 12 .

[0087] Because scene recall is a pre-programmed event, the distributed controllers 12 can also each perform pre-programmed additional actions in response to the scene recall, such as controlling the light sources of the luminaires 16 (these controllers are integrated into the luminaires 16). The scenes stored in the slave devices 14 and the distributed controllers 12 can be stored in the memory of each device.

[0088] In phase 3, when another distributed controller in the same group or after the default interval is reached by the same controller (DC i ) detects a person leaving a room or another motion event, it can report the detected motion to other distributed controllers (DCs) after a predetermined event registration interval. j≠i With respect to the socket control, this event causes a command to be sent ( Recall_Scene_1 ) and reload the SD OFF timeout timer (reload SD_OFF_Timeout ). Because the slave device 14 is already in the ON state, no additional action is taken.

[0089] like Figure 8B As shown in Figure 8A Continuation of Phase 3 shown in, when the room is unoccupied, the SD OFF timeout timer ( Recall_SCENE_2 ) expires, which results in the deactivation of the relays in the slave devices and the rest of the distributed controllers (DC j≠i ) in the deactivation command (e.g. by deactivating the timer). Note that sending ( Recall_SCENE_2 ) message does not have to be the controller that activates the plug load controller, this can be performed by any distributed controller 12.

[0090] In one embodiment, when the scene recall command is heard by all members of the group, a unique wait timer is not required. In another embodiment, (e.g., when there is a higher density of sensors) there is still an initial unique delay for the command announcing the change of state from occupied to unoccupied to prevent sending multiple multicast messages triggered by multiple sensors.

[0091] While group communications using broadcast, multicast, or multicast mechanisms are described above, those skilled in the art will appreciate that, in alternative embodiments, the same goal may be achieved by sending multiple unicast messages in rapid succession.

[0092] Although several inventive embodiments are described and illustrated herein, those skilled in the art will readily conceive of various other devices and / or structures for performing the functions described herein and / or obtaining the results and / or one or more advantages described herein, and each of such variations and / or modifications is considered to be within the scope of the inventive embodiments described herein. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are exemplary, and that actual parameters, dimensions, materials, and / or configurations will depend on the specific application or applications in which the teachings of the present invention are used. Those skilled in the art will recognize, or be able to ascertain using only routine experimentation, many equivalents to the specific inventive embodiments described herein. Therefore, it should be understood that the foregoing embodiments are presented by way of example only, and that, within the scope of the appended claims and their equivalents, the inventive embodiments may be practiced otherwise than as specifically described and claimed. The inventive embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods, provided such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent, is included within the inventive scope of the present disclosure.

Claims

1. A distributed control system (10), comprising: A plurality of controllers (12), each controller (12) of the plurality of controllers (12) communicating with the remaining controllers (12) of the plurality of controllers (12), each controller (12) being configured to control at least one device (14), each controller (12) being further configured to: In response to the received signal, starting a first timer having a length that is unique relative to lengths of the first timers of remaining controllers (12) in the plurality of controllers (12); sending a first notification signal to the remaining controllers (12) upon expiration of the first timer, the first notification signal notifying the remaining controllers (12) of an intention to send a command signal; and The command signal is sent to the at least one device (14), wherein the controller (12) is configured to cancel sending the first notification signal and the command signal if the first notification signal is received from one of the remaining controllers (12) of the plurality of controllers (12) before the first timer expires.

2. The distributed control system of claim 1 , wherein each controller ( 12 ) is further configured to: starting a second timer that expires after the first timer expires, the second timer having a length that is unique relative to the second timer lengths of the remaining controllers (12) in the plurality of controllers (12); In the event that the second timer expires, sending a second notification signal to the remaining controllers (12), the second notification signal notifying the remaining controllers (12) of the intention to send the second command signal; and The second command signal is sent to the at least one device (14), wherein the controller (12) is configured to cancel sending the second notification signal and the second command signal if the second notification signal is received from one of the remaining controllers (12) of the plurality of controllers (12) before the second timer expires.

3. The distributed control system (10) of claim 2, wherein each controller (12) is further configured to: start a third timer, wherein: The length of the third timer is the same throughout the remaining controllers (12) of the plurality of controllers (12) and is longer than the length of the first timer; and In response to expiration of the third timer, the second timer is started.

4. The distributed control system (10) of claim 1, wherein the at least one device (14) is a plug load control device (14).

5. The distributed control system (10) of claim 4, wherein the first command signal is an on command configured to cause the plug load control device (14) to cause power to be delivered to the outlet.

6. The distributed control system (10) of claim 1, wherein the received signal is a sensor signal.

7. The distributed control system (10) of claim 6, wherein the received signal is received at only a subset of the plurality of controllers, wherein the notification signal further notifies at least one of the remaining controllers (12) of the detected motion.

8. The distributed control system (10) of claim 6, wherein the sensor signal is generated at a sensor (30) coupled to at least one controller (12) of the plurality of controllers (12).

9. The distributed control system (10) of claim 8, wherein a controller (12) coupled to the sensor (30) is configured to communicate the sensor signal to other distributed controllers (12).

10. The distributed control system (10) of claim 1, wherein the received signal is received from another controller (12) of the plurality of controllers (12).

11. The distributed control system (10) of claim 2, wherein the second command signal is a shutdown command.

12. The distributed control system (10) of claim 1, wherein the length of the first timer is randomly set and has a maximum possible value.

13. The distributed control system (10) of claim 1, wherein each controller (12) includes a corresponding wireless module, and each controller (12) communicates with the remaining controllers of the plurality of controllers (12) through the wireless module.

14. The distributed control system (10) of claim 1, wherein each controller (12) is further configured to: starting a timer, the second timer having a length that is unique relative to the second timer lengths of the remaining controllers (12) in the plurality of controllers (12); A second command signal is sent to the remaining controllers (12) and the at least one device (14), wherein the remaining controllers (12) and the at least one device (14) recall second pre-stored settings in response to the second command signal.

15. A method for use in a distributed control system (10), the distributed control system (10) comprising a plurality of controllers (12), each controller (12) of the plurality of controllers (12) communicating with the remaining controllers (12) of the plurality of controllers (12), each controller (12) being configured to control at least one device (14), the method comprising each controller (12) performing the following steps: In response to the received signal, starting a first timer having a length that is unique relative to lengths of the first timers of remaining controllers (12) in the plurality of controllers (12); In the event that the first timer expires, sending a first notification signal to the remaining controllers (12), the first notification signal notifying the remaining controllers (12) of the intention to send the command signal; and The command signal is sent to the at least one device (14), wherein the controller (12) is configured to cancel sending the first notification signal and the command signal if the first notification signal is received from one of the remaining controllers (12) of the plurality of controllers (12) before the first timer expires.

Images