Programming rules for controlling lighting based on user interactions with one or more actuators in one or more zones

A method of programming a respective rule for controlling lighting in each of one or more zones each being occupiable by a user. The method comprises: detecting that a user has actuated one or more actuators serving a zone presently occupied by the user; receiving a user selection through a user interface of a user terminal, to select one or more illumination sources arranged to illuminate the zone presently occupied by the user; and 5 based on this detection and user selection, automatically programming a respective rule into a memory in association with the one or more actuators, the rule specifying how the illumination emitted by the one or more selected illumination sources is to be controlled as a function of a subsequent instance of said user interaction.

CROSS-REFERENCE TO PRIOR APPLICATIONS

This application is the U.S. National Phase application under 35 U.S.C. § 371 of International Application No. PCT/EP2017/066788, filed on Jul. 5, 2017, which claims the benefit of European Patent Application No. 16178629.8, filed on Jul. 8, 2016. These applications are hereby incorporated by reference herein.

TECHNICAL FIELD

The present disclosure relates to the programming of rules for controlling the illumination emitted by illumination sources in response to the actuation of user-actuated actuators such as switches or presence sensors.

BACKGROUND

US 2016/170389 A1 discloses using an external programming terminal to program smart buttons.

US 2015/332586 A1 discloses using a graphical user interface to program smart buttons.

Connected lighting refers to a system of one or more luminaires which are controlled not by (or not only by) a traditional wired, electrical on-off or dimmer circuit, but rather by using a data communications protocol via a wired or more often wireless connection, e.g. a wired or wireless network. Typically, the luminaires, or even individual lamps within a luminaire, may each be equipped with a wireless receiver or transceiver for receiving lighting control commands from a lighting control device according to a wireless networking protocol such as ZigBee, Wi-Fi or Bluetooth (and optionally also for sending status reports to the lighting control device using the wireless networking protocol). The lighting control device may take the form of a user terminal, e.g. a portable user terminal such as a smartphone, tablet, laptop or smart watch; or a static user terminal such as a desktop computer or wireless wall-panel. In such cases the lighting control commands may originate from an application running on the user terminal, either based on user inputs provided to the application by the user through a user interface of the user terminal (e.g. a touch screen or point-and-click interface), and/or based on an automatized function of the application. The user equipment may send the lighting control commands to the luminaires directly, or via an intermediate device such as a wireless router, access point or lighting bridge.

Home automation systems are now being proposed in which the functionality of the system can be managed by end-users, such as to enable the user him- or herself to define what switches and/or sensors will trigger what luminaires to exhibit what behavior. For example an application (or “app”) running on a mobile user terminal such as a laptop, tablet, smartphone or smart watch, or a status user terminal such as a desktop computer, may be used by non-technical users to configure the behavior of an automated home lighting system.

SUMMARY

Programming a home automation system should indeed ideally be a user action, so it can be tailored towards the specific application context. A difficulty in realizing this, however, is in providing a mechanism that enables an end-user without technical expertise to readily create usable, understandable home automation patterns.

According to one aspect disclosed herein, there is provided method of programming a respective rule for controlling lighting in each of one or more zones each being occupiable by a user, the method comprising: (a) detecting that a user has performed a first instance of a user interaction with one or more user-actuated actuators serving the zone presently occupied by the user, the user interaction comprising at least one actuation of each of the one or more actuators (e.g. pressing a physical switch, such as a wall switch, or triggering a presence sensor); (b) receiving a user selection through a user interface of a user terminal, the user selection selecting one or more illumination sources arranged to illuminate the zone presently occupied by the user (e.g. selecting the sources through lighting control app running on a mobile device carried by the user); and (c) based on said detection and user selection, automatically programming the respective rule into a memory in association with the one or more actuators, the rule specifying how the illumination emitted by the one or more selected illumination sources are to be controlled as a function of a subsequent instance of said user interaction; wherein the method further comprises, on a subsequent occasion following the performance of (a), (b) and (c), reading said rule from the memory in order to automatically enact the rule in response to the subsequent instance of the subsequent interaction and thereby control the illumination.

Thus there is provided a system which learns from the end-user performing the actual actions he or she intends to have trigger certain lighting events in different regions around the home, office, or the like. For instance the zones may be rooms of the user's home. In this case the user may walks around his or her home pressing lighting switches and/or triggering presence sensors, and assigning a lighting response to each switch or sensor as he or she does so, e.g. through a lighting control app on a smartphone or tablet. This provides a much more intuitive mechanism for a user to program a lighting system.

In particularly preferred embodiments, the method comprises: (d) upon the receipt of said user selection, automatically controlling the one or more selected illumination sources to emit illumination in accordance with said rule, thereby demonstrating to the user the rule being programmed (wherein said subsequent occasion follows (a), (b), (c) and (d)).

Hence in embodiments, the invention advantageously provides the user with a method of learning by doing. I.e. by the user actually controlling the selected light source or sources in the manner that he or she wishes, including actually causing them to emit the desired lighting effect, the system automatically remembers this so that the next time the user actuates the same actuator (e.g. a physical switch, such as a wall switch, a sensor, etc.) then this will automatically have the same function.

Note that steps (a), (b), (c) and (d) do not necessarily have to be performed in any particular order, except that (c) and (if used) (d) must causally-speaking come after (a) and (b). Therefore (b) may be performed after (a), or (a) may be performed after (b); and (c) may be performed after (d), or (d) may be performed after (c).

Note also that the memory comprises one or more memory units of one or more storage media, and where it is said a certain piece of information is stored in “the” memory, or such like, this does not necessarily mean stored in the same one of the memory units as a previously-recited one of the pieces of information stored in the memory (though it could be).

In embodiments, said one or more zones are a plurality of zones (e.g. rooms of a house, areas of a garden, etc.) and the method comprises repeating operations (a), (b) and (c) to program the respective rule in each of the plurality of zones.

In embodiments, the method may further comprise: presenting a start control and a stop control to the user though the user interface, activating a record mode when the user activates the start control, and ending the record mode when the user activates the stop control; wherein the repeated performance of (a), (b) and (c) (and optionally (d)) is automatic on condition of the record mode being activated, so as to automatically program the respective rules for the zones visited by the user during the record mode; whereas when the record mode is deactivated then the subsequent instance of said user interaction automatically invokes the enacting of said rule to control the illumination. In embodiments the record may be deactivated either manually or automatically, e.g. automatically after a time out.

In embodiments, the method may further comprise: during the record mode, storing in the memory a record of the zones visited by the user and/or the actuators for which one of said rules has already been programmed; and when the user returns to one of the zones for which the respective rule is already programmed, recalling said record from memory in order to avoid reprogramming the respective rule.

In embodiments, the user interaction may comprise multiple actuations by the user of at least one of the one or more actuators, and said function may comprise a different respective action to be triggered by each of the multiple actuations.

In embodiments, the automatic programming of the rule is performed on condition that the multiple actuations are performed within a predetermined time window relative to one another.

In embodiments, the automatic programming of said rule may be performed on condition that the user selection and the first instance of the user interaction are performed within time window relative to one another.

In embodiments, at least one of said one or more actuators may comprise a switch, button, dial or slider; and the user interaction comprises the user pressing the switch or button, turning the dial or sliding the slider, respectively. The switch, button, dial or slider may be a physical switch, physical button, physical dial or physical slider, respectively. For example, a wall switch. In other words, the actuator is a real object and not a virtual object that is part of a graphical user interface. In embodiments, at least one of said one or more actuators may comprise a presence sensor, and said user interaction comprises the user being sensed by the presence sensor.

In embodiments, the method may comprise receiving a user input through the user interface specifying a value of a parameter qualifying an additional condition of the rule. E.g. the parameter may be time of day, the value being a time or a range of times, this qualifying the rule in that the rule only applies before or after the user specified threshold time or within or outside the user specified range of times, or the rule comprises different variants which are applied depending on whether the current time of day is inside or outside the user specified range.

In embodiments, the method may comprise receiving a user input through the user interface, the user input selecting the rule from a set of predefined templates. In embodiments, the rule may be defined by a predetermined template sourced from a rule created by one or more other users.

Thus the user can be aided in creating home automation rules by reusing home automation behavior created by other apps or users on their respective systems, or from shared behavior of other cloud connected systems.

According to another aspect disclosed herein, there is provided a computer-program product comprising code embodied on computer-readable storage and configured so as when run on one or more processing units to perform operations in accordance with the method of any embodiment disclosed herein.

According to another aspect disclosed herein, there is provided lighting control equipment comprising a controller configured to perform operations in accordance with the method of any embodiment disclosed herein. According to another aspect there is provided a lighting system comprising the lighting control equipment and the light sources, the light sources being coupled to the lighting control equipment via a wired and/or wireless connection in order to enable the control of the light sources.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1illustrates an example of an environment2in which embodiments disclosed herein may be applied. The environment2may comprise any indoor, outdoor and/or partially covered space such as the interior of a building, a garden and/or a gazebo, respectively. Furthermore the environment2is divided into a plurality of different zones3fit to be occupied by a human user10, e.g. rooms of a house or different areas of a garden. The illustrated example shows part of the interior of a user's home (house or apartment) comprising three rooms, e.g. say a living room3a, a kitchen3cand a corridor3bbetween them. More rooms may also be involved but only three are shown for illustrative purposes. Embodiments may be described in terms of an example in which the zones3are rooms, but it will be appreciated that this is not limiting and the teachings herein may apply to other scenarios such as different areas in a user's garden.

Each of the rooms3is equipped with a respective one or more illumination sources4in the form of one or more luminaries, arranged to illuminate the respective room3. Each of the luminaires4comprises one or more lamps (i.e. the actual light emitting component or components) plus any associated housing, socket and/or support. In the illustrated example the luminaires4are mounted on the ceiling of the rooms3, but alternatively or additionally, one, some or all of the luminaires4may take other forms such as wall-mounted luminaires, wall washers, free-standing luminaires, task lighting, or less conventional forms such as a luminous panel embedded in an item of furniture.

The user10has a mobile user terminal8disposed about his or her person, e.g. held in the hand, or worn on the user's body. In embodiments the user terminal8may for example take the form of a smartphone, tablet or even smartwatch. As will be discussed in more detail shortly in relation toFIG. 2, the user terminal8comprises a user interface14through which the user10can control the light emitted by the luminaires4. Typically the user interface14takes the form of a touch screen, but other forms are not excluded (e.g. an audio interface with voice recognition).

Each of the rooms3is also equipped with at least one respective actuator5,6suitable for use to control one, some or all of the luminaires4in the environment2. For example the actuator(s) in each given room3may comprise one or more hand-actuated actuators5such as light switches, buttons and/or dials or sliders (e.g. dimmers), which may for instance be mounted on an interior wall of the room. Each of the light switches5may for example take the form of a wireless “smart switch”. As another example one or more of the actuators5may comprise a power plug and socket, with the system comprising detection means (not shown) to detect when the user actuates or de-actuates an illumination source4by plugging the plug into a power socket or unplugging the plug from the socket, respectively, and to output a “turn on” or “turn off” signal when this is detected. The following will be described by way of example in terms of switches, but it will be appreciated that these could equally take the form of buttons, sliders, rotational dials or such like. In general any means that has the capability to detect when a lamp is switched on and off may be used as an actuator. Note also that the actuator does not necessarily have to be in the same room as the illumination source which it is to control. E.g. for an illumination source in garden, the (or another) switch or other actuator may be located in a room inside the house.

Alternatively or additionally, actuator(s) in each given room3may comprise one or more presence sensors6arranged to detect presence of the user upon entering the room. Each of the presence sensors6may take any of a variety of forms, the form of a passive infrared sensor, active ultrasound sensor, or a 2D or 3D (depth aware) camera. Further, the presence sensor6may detect presence of a person10based on any of a variety of criteria, for example based on detecting motion using the Doppler effect and assuming this is the movement of a living being, or by using an image recognition algorithm to recognize a human face or the shape of a human body in the images captured by a camera. Another form of presence sensor comprises a wearable device worn about the user's person, which reports when the user10is in a given room3. Various forms of presence sensor are in themselves familiar to a person skilled in the art and for conciseness the detailed workings of presence sensors will not be reproduced here.

FIG. 2illustrates a system according to embodiments of the present disclosure by which the user10can define, in a user-friendly manner, which of the actuators5,6controls which of the luminaires4, and what effect this will have. In addition to the components already described in relation toFIG. 1, the system comprises a controller12, and a storage location16(i.e. memory) for storing one or more lighting control rules18.

The controller12is operatively coupled to each of the luminaires4, the light switches5and/or the presence sensors6, the user interface14of the mobile device8, and the storage16. Via the respective coupling, the controller12is thereby arranged to be able to control each of the luminaires4, to receive inputs from each the switches5and/or presence sensors6, to receive user inputs from the user10and output content to the user10through the user interface14, and to store values of the lighting control rules18in the storage location16. The manner in which the various components4,5,6,14,16are coupled to the controller12in order to enable this functionality may be implemented in using any of a variety of possible wired and/or wireless connections, for example as follows. The controller12itself may also be implemented in any of a number of possible forms and at any of a number of possible physical locations.

In embodiments the controller12is implemented in the form of code stored on a memory and arranged to be run on a processing apparatus (and the memory on which the controller12is stored may comprise some or all of the same memory the storage location16storing the lighting control rules18, or a different memory). The processing apparatus on which the controller12is run may comprise one or more processing units at one or more physical locations (distributed processing techniques are in themselves known in the art).

Similarly the memory on which the controller12is stored may comprise one or more memory units located at one or more physical locations, as may the memory16on which the lighting control rules18are stored. E.g. either or both memories may be implemented in the form of one or more magnetic memory units such as a hard disk which use a magnetic storage medium, and/or one or more electronic memory units such as an EEPROM (or “flash” memory) which use an electronic storage medium, and/or even one or more optical storage units which use an optical storage medium. Further, note that the physical locations at which the processing apparatus and either or both memories are located may be the same or different.

Alternatively it is not excluded that the controller12may be implemented in the form of dedicated hardware circuitry, or configurable or reconfigurable hardware circuitry such as a PGA (programmable gate array) or FPGA, or any combination of hardware or software.

In embodiments, the controller12may comprise a lighting control application (or “app”) installed on a local memory of the mobile user terminal8and arranged to run on a local processing apparatus of the mobile user terminal8(i.e. a memory and processing apparatus included in the mobile user terminal8). In this case the controller12receives inputs from, and outputs content to, the user interface14via an internal wired connection between the controller12and user interface14—typically a touch screen. To control the luminaires4, the controller12controls these via an at least partially wireless connection between the mobile terminal8and each of the luminaires4, either via a direct wireless connection or via one or more intermediate components such as a wireless access point, lighting bridge, buildings controller or server (not shown). This connection could be wireless all the way from the mobile terminal8to the luminaires4, or may comprise a wired leg between the intermediate component and the luminaires4. For example in embodiments the controller12may control the luminaires4via an individual direct wireless connection between the mobile terminal8and each of the luminaires4, e.g. a ZigBee, Bluetooth or Wi-Fi connection. Alternatively the mobile device8may form a wireless connection via a wireless local area network (WLAN), e.g. via a lighting bridge or wireless access point. Or the mobile device8may connect to an intermediate component such as an access point, lighting bridge, buildings controller or server and then onwards from there to the luminaires4via a wired connection such as a local Ethernet or DMX network, or via the Internet.

To receive inputs from the switches5and/or sensors6, the controller12again uses an at least partially wireless connection between the mobile device8and each of the switches5and or sensors6. This could be via the same type of connection as that used to control the luminaires4, or a different type of connection. E.g. the controller12may receive inputs from the switches5and/or sensors6either via a direct wireless connection or via one or more intermediate components such as a wireless access point, lighting bridge, buildings controller or server (not shown). This connection could be wireless all the way between the mobile terminal8and switches/sensors5,6, or may comprise a wired leg between the intermediate component and the switches/sensors5,6. For example in embodiments the controller12may receive the inputs from the switches5and/or sensors6via an individual direct wireless connection between the mobile terminal8and each of the switches5and/or sensors6, e.g. a ZigBee, Bluetooth or Wi-Fi connection. Alternatively the mobile device8may form a wireless connection via a wireless local area network (WLAN), e.g. via a lighting bridge, or wireless access point. Or the mobile device8may connect to an intermediate component such as an access point, lighting bridge, buildings controller or server, with the connection completed via a second, wires leg such as via a local Ethernet or DMX network, or via the Internet.

When the controller12is implemented on the user terminal8, the memory16used to store the lighting control rules18may comprise the (or a) internal memory of the user terminal8, or may comprise a remote (external) memory such as on a server. In the latter case the controller12may be configured to read and write from the memory18via a connection over any wired and/or wireless network, e.g. via a WLAN, a local Ethernet network, a mobile cellular network and/or the Internet.

In alternative embodiments, the controller12may be implemented on a central control equipment external to the mobile device8, e.g. on a server, building controller or lighting bridge, and may merely be accessed through the user interface14on the terminal8. In this case the controller12may form the connections with the luminaires4, switches5and/or sensors6for the purposes disclosed herein via any suitable wired and/or wireless network, for example via the Internet, via a mobile cellular network, via a WLAN in the locality of the environment2(e.g. using Wi-Fi, ZigBee or Bluetooth), and/or via a local Ethernet network in the locality of the environment2. For instance, in one example the controller12may be implemented on a lighting bridge (not shown) located physically in the environment2, and which directly connects to each of the luminaires4, the switches5and/or sensors6, and the user interface14on the mobile device8via a direct wireless connection with each (e.g. a ZigBee connection) or via a local wireless network such as a Mesh network (e.g. again using ZigBee). As another example, the controller12may be implemented on a server (again not shown), which may comprise one or more physical server units located at one or more geographical sites. E.g. the controller12may be hosted on the cloud. In such cases the controller12may again connect from the server to each of the luminaires4, switches5and/or sensors6, and the user interface14on the mobile device8via any suitable wired and/or wireless network, e.g. again via the Internet, a mobile cellular network, a WLAN and/or a local Ethernet network. For instance the controller12may form a connection comprising a leg via the Internet between the server and a wireless access point in the environment2, and a further, wireless leg between the wireless access point and each of the luminaires4, switches5, sensors6and/or the user terminal8.

In one particular example, the controller12may be implemented in the form of a web-based service accessed through a general-purpose web-browser application running on the user terminal8.

When the controller12is implemented on a centralized entity such as a server or lighting bridge, the memory16used to store the lighting control rules18may comprise server or bridge's own memory, or may comprise a remote (external) memory such as on the user terminal8or another entity (e.g. a server provided by another party). In the case of a memory or the server or bridge's own memory, the controller12may be configured to read and write from the memory18via a connection over any wired and/or wireless network, e.g. via a WLAN, a local Ethernet network, a mobile cellular network and/or the Internet.

In further alternative embodiments, the controller12may be distributed between the mobile terminal8and the centralized entity (e.g. server or lighting bridge). For instance in embodiments the functionality of the controller12dealing with the user interface14may be implemented on the user terminal8whilst the functionality controlling the luminaires4and detecting the signals from the switches5and/or sensors6may be implemented on the server to bridge. In such embodiments the connections between the user terminal8, server/bridge and various other components4,5,6may be implemented via any of the above described means.

In yet further alternative embodiments, the controller12may be implemented in a highly distributed form in embedded software or hardware logic distributed throughout multiple of the luminaires4, switches5and/or sensors6, and optionally also the user terminal8. In such embodiments, the memory16on which the lighting control riles18are stored may be implemented in any one of the components4,5,6,8or another component such as a server or lighting bridge, or may be distributed throughout multiple of any such components. In such embodiments the various connections involved in communicating between the various components4,5,6,8,14,16may be implemented via any suitable wired and/or wireless technology, e.g. a ZigBee Mesh network.

In general, where any of the functionality herein involves communication between components4,5,6,8,14,16, these may be implemented via any of the above-mentioned wired and/or wireless means and/or other such means. For brevity the various options will not be repeated each time but it will be understood that such communication means are used.

As mentioned, embodiments of the present disclosure provide a mechanism by which a user can readily program lighting control rules18with little or no technical expertise or experience. To this end the controller12may be configured to conduct a method as follows.

To begin the process the user10selects an option presented through the user interface14on the mobile terminal8to enter the controller12into a “record mode”, to begin recording user inputs that will be programmed to trigger a lighting response. Once in the record mode, the controller12is set so as to capture user inputs received through the actuators5,6(e.g. switches5and/or sensors6) as being targets for being programmed. Optionally the record mode could be excluded so that the controller12has this behavior unconditionally (e.g. whenever the app is open on the user terminal8). However, an explicit record mode is preferred so as to mitigate unintentional recording of lighting control rules later when the lighting system in normal, everyday use.

Reference is now made toFIG. 3in addition to the previously-introducedFIGS. 1 and 2.

Once recording, the controller12detects whenever the user10actuates one of the actuators5,6. This may comprise for example the user pressing one of the switches5(or turning a dial, sliding a slider, etc.) or the user10walking into the field of view of one of the presence sensors6. The controller12then presents a name or some other identification or the actuated actuator(s)5,6to the user10through the user interface14of the mobile device8. See for example the left-hand screen shot inFIG. 3.

In addition, the controller12presents to the user10through the user interface14a set of options for lighting behavior to be associated with the recently actuated actuator5,6. For instance the options may comprise multiple different ones of the luminaires4in the environment2or in the particular room3currently occupied by the user10or (which the controller12may be aware of through a pre-programmed commissioning database, or by detecting their proximity using the wireless interface between the controller12and the luminaires4). Alternatively or additionally, the set of options may comprise multiple different lighting effects for a given one or more of the luminaires4, e.g. turn on its illumination, turn off its illumination, dim up its illumination, dim down its illumination, change the color of its illumination, etc.

Note also that in some embodiments, the controller12could be implicated in the form of more than one application arranged to interface with one another. E.g. the programming functionality (the ability to associate actuators5,6with selected lighting effects) may be implemented in one application provided by one party such as a provider of the lighting system and/or actuators, while the ability to select or design lighting effects through the user interface14may be implemented in another application provided by another party, such as a third party writing apps to accompany the lighting system provider's lighting system.

In the example ofFIG. 3, the user10spresented with the option to associate the actuated activator5,6with the turning on of the illumination from one or more of four available luminaries4(or even individual lamps within a luminaire, though note that the term “lamp” may be used colloquially by end-users to refer to what is technically a luminaire, so the menu may in fact use the more colloquial but technically incorrect terminology more familiar to end users).

When the user selects one of the presented options, the controller12then automatically associates the selected lighting behavior with the one or more actuated actuators5,6, and stores this association as one of the lighting control rules18in the relevant storage location16(e.g. local memory of the user terminal8, in a lighting bridge, in a buildings controller or in a server). In embodiments the controller12performs this step on condition that the user selects one of the options within a predetermined time interval running from the time the user actuated the actuator (or at least when the controller12received the notification of the actuation from the actuator5,6). Otherwise the step times out such that the controller automatically cancels the programming of a rule18associated with the actuated actuator5,6, or even the process as a whole may time out (i.e. the programming mode is exited). Alternatively it is not exploded that there is no time-out feature such that the record mode is left pending indefinitely, or until the user manually cancels the step or manually exits the record mode.

In some cases, a lighting control rule18may also comprise a certain condition qualifying the performance of that rule, e.g. the switch5or sensor6will only trigger its programmed behavior after a certain threshold time of day, or after a certain threshold time of day, or inside or outside a certain time range. In such cases the controller12, at the time of programming the rule18, may also prompt the user10through the user interface14to input a value of one or more parameters qualifying the condition of the rule. E.g. in the case where the condition comprises a time of day before or after which the rule applies, or a range of times during or outside of which the rule applies, the user is prompted to input the threshold time or the range of times. As another variant of this, instead of the rule18either applying or not applying depending on the condition, the rule18may comprise different variants depending on the value of the condition, e.g. depending on time of day. For instance the user may program a switch5or sensor6will have a first effect before a certain user-specified time of day but a second behavior after, or a first effect during a certain user-specified range of times but a second behavior outside. E.g. a switch5or sensor6may be programmed so that before a certain user-specified in the evening it turns on its associated luminaire4to emit white light, but after the threshold time in the evening it instead turns on the luminaire4to emit a warmer colored light such as amber light.

Once the rule18is programmed then, in future, when the user actuates the programmed actuator(s)5,6in an operational phase after then end of the record mode, the controller12will automatically enact the associated programmed lighting effect (e.g. turning on the associated luminaire or luminaires, or switching its or their color, etc.).

Preferably when the user10selects the desired behavior to associate with the one or more actuated actuators5,6, then as well as programming the rule18, the controller12also automatically controls the selected luminaire(s)4to actually enact the selected lighting behavior. E.g. if the user10selects to turn on luminaire A, then as well as programming this function to be associated with the actuated actuator(s)5,6when actuated in the future, this will also turn on the illumination from luminaire A at the present moment; or if the user10selects to set luminaires A-D to red, then as well as programming this function to be associated with the actuated actuator(s)5,6when actuated in the future, this will actually cause luminaires A-D to emit red illumination at the present moment. Thus the end user10is advantageously provided with a system which he or she can program according to a “learning by doing” paradigm.

Optionally in some embodiments, or for some actuators5,6or for some luminaires4, the controller may enable a sequence of functions to be associated with successive actuations of an actuator5,6. Say for example the actuator in question is a switch or button5. If the user presses the switch or button two or more times in succession (and in embodiments on condition of each press or actuation being within a predetermined time window running from the last), then the controller12presents the user10(again through the user interface14) with the option to associate a different function with each successive press or actuation. E.g. in the example ofFIG. 3, the first time the user10presses the switch5, the controller12presents the user10with the option of associating the first press with the turning on of any one or more of four available luminaires A-D, whereas the second time the user10presses the switch, the controller12presents the user10with the option of associating this with the turning off of any one or more of the four available luminaires4. The controller12then programs the user's selection as a rule18in the database16, such that in future, in an operational phase after the end of the record mode, then when the user presses the switch5twice it will have a toggle behavior in accordance with the programmed rule.

As another example, the user could select that successive presses dim up the emitted illumination in degrees, or cycles through different color settings. Also a similar concept could be applied for presence sensors i.e. the first time the presence sensor is triggered this causes a first lighting effect, and the second time the presence sensor is triggered then this will case a second, different effect.

Furthermore, whether only a single actuation or a sequence of actuations are programmed for a given actuator5,6, the controller12is configured to allow the user10to continue programming further actuators5,6in different zones3throughout the environment2. For instance this may continue as long as the controller12is still in the record mode. Preferably, the controller12is configured to remember which actuators5,6have already been programmed and refrain from presenting the user10with the option to reprogram these if actuated again during the same continuous session of the record mode. Or as variant of this the controller12may remember which zone(s)3the user10has already visited during the same continuous session of the record mode and refrain from presenting the user10with any options to program any actuator5,6if actuated when the user10returns to the previously visited zone(s)3. Such a feature is especially useful if one or more of the actuators are presence sensors6.

Say for example the user10begins by selecting to start the record mode whilst presently in the living room3a(refer again toFIG. 1). The user10then presses a light switch5aor triggers a presence sensor6ain that room, is presented with lighting behavior options through the user interface14of his or her mobile device8, selects an option to program, and in embodiments also sees this lighting behavior actually enacted as it is programmed. The user then goes out into the corridor3bwhere he or she presses another switch5bor trips another presence sensor6b. In response the user10is presented with another set of lighting behavior options, and again selects an option to program (and again preferably also sees this lighting effect actually rendered at the same time). Next, the user10goes from the corridor3binto the kitchen3cwhere the same procedure is repeated again.

Having programmed the lights in these rooms3a-3c, the user10now wishes to program the lights in another room (not shown), e.g. perhaps another room on the ground floor or a room upstairs, e.g. on the landing or a room off the landing. This will involve the user returning back through the corridor3b. In doing so, the user10will trip again the same presence sensor6balready programmed the last time the user went through the corridor during this same session of the record mode, or perhaps the user10may reach for one of the same light switches5bthat was already programmed, simply to turn on the lights to find his or her way upstairs rather than because the user10wants to reprogram this. To accommodate this, preferably in embodiments the controller12is configured to store a record of the fact that the user10already programmed the switch5bor sensor6bin the corridor in the present session of the record mode, and/or that the user10already visited the corridor3bduring this session of the record mode. Based on this, the controller12will avoid presenting the user10with any more programming options as he or she passes through the corridor, until the user reaches the next new room or actuates a new, programmed actuator5,6.

Note however: not all embodiments include the feature of automatically ignoring previously programmed or encountered actuators5,6, or actuators in previously visited regions3. For instance some actuators5,6may be used in multiple behaviors. E.g. the user10may want presence in room X (e.g. hallway3b) to cause dimmed light in room Y (e.g. living room3a), in which case the user might wish to re-use the same sensor6that was already programmed when the user visited room X and taught the living room sensor6to switch on the living room. As another example, it might be desired that some lights between kitchen and living room switch on in case of motion in the kitchen as well as motion in the living room. Thus in embodiments, the controller12is not configured to refrain from offering the same actuators5,6again.

As a variant of this, the controller12may be configured to provide the user with a choice to either ‘ignore’ actuators5,6that already have behavior assigned (or have already been encountered or that are in regions3that have already been visited) or to ‘use everything’ (do not ignore). The choice may for example be a user setting, or could be presented automatically each time the user10visits a previously visited area3. In embodiments, the controller12may be configured to allow the user to modify a recording by adding and/or removing steps manually (see later).

Once the user10is finished programming all the desired behaviors in the environment (e.g. house or apartment)2, the user10selects an option in the user interface14to end the record mode. In response the controller12places the system into the operational phase where actuating any of the actuators5,6will now have the programmed effect. If the user10wishes to reprogram any behaviors, he or she can simply select through the user interface14to restart the record mode (this starting a new record session).

In some embodiments, the programming may be based on one or more templates. A template is a set of rules, schedules, and/or state variables with a parameterized set of sensors and actuators. The templates could be extracted for example from a lighting bridge's or server's collection of rules, schedules, and state variables controlling the same lights4, e.g. either from a specific room3in the system, or recognized in the cloud as common behavior among a large set of users. Users can apply a template to a room3and have the sensors6, light switches5, and lights4in the room filled in as default.

As mentioned, creating home automation behavior can be difficult for novice users and requires technical expertise. For example, imagine a stairway where a single button5on the first floor and a single button5on the second floor can be used to toggle a light on and off when walking the stairs: a simple behavior that—when explained to someone—is easy to understand. However, to program this requires a state variable (for the toggle), rules to change the state when a button is pressed, and rules to change the lights if the state variable changes. The step from the conceptual idea to the implementation in the system is not trivial for the average user. Now imagine the lights should also be at a lower brightness at night, or switch off automatically after 5 minutes. These add more rules and schedules to the home automation behavior making it harder for the novice user to realize this behavior.

Nonetheless, various expert users may have already create relevant behavior for their homes. In embodiments, these are reused by offering them to other users, allowing the differences recognizable to the users (switches lights, timer values) to be configured. This would simplify setting up a home automation system as the step from conceptual model to implementation is shared across users. Additionally, other users can be inspired by the capabilities of their system by seeing what others have done. Further, based on the sensors and other actuators present in the system, a more user-friendly approach can be provided by suggesting switches and lights of the current or another room to be used.

A related problem is to know what behavior is relevant and/or possible for a specific room3or home. In embodiments, there is provided a cloud infrastructure to which multiple lighting systems are connected and which can detect common behavior in rooms with a similar set-up, and provide these as suggestions for a user's home. This will simplify finding relevant home automation behavior.

The templates for smart home applications may be created by an active development community, or by the manufacturer of the lighting technology. However, creating such a template can be complex and requires technical knowledge. In embodiments disclosed herein there is provided a simpler way of applying templates to a lighting system, by allowing people to show their system how they want it to behave. According to such embodiments there is provided an interface with a mixed initiative, whereby the user10can manually set specific behaviors, and the system makes suggestions to the user.

By way of illustration, a particular example involving the record mode and templates is now described with reference toFIGS. 3 to 6.

As mentioned, in embodiments the user10begins by activating a ‘recording mode’. In the recording mode the user can tell the system how it should behave. For example, the user activates the recording mode and takes the following action: (I) Press a smart switch5or a certain button of the smart switch if it has more than one button, (II) switch on four lights4in the system through the user interface14of the mobile device8, (III) press the switch again or press the same button of the switch5, and (IV) use the user interface14of the mobile device8to switch off four lights in his system. Thus the user10teaches the system by performing the action(s) he or she wishes to program, and controlling the lights4in the way he or she wants to associate with the performed action(s). After that, the user deactivates the recording mode.

During the recording mode the steps that are added to the recording may be visualized to the user in a graphical user interface14.FIG. 3shows an example of such an interface. With every action the user takes, a new step is added in the recording. The figure shows how the example describe above might be visualized.

In embodiments, the next step is matching the user's selection to a template. Once the recording phase has ended the controller12knows which accessories should take part in the template. In the example above (see alsoFIG. 3) it knows that a certain switch5and two light states are used. It also knows the settings of the two light states (state 1: lights on, state 2: lights off) and the order of execution. With this information it can search a database of existing templates to find all templates that match these criteria. If a suitable template has been found the user10can select that template and the information that the user has provided will be entered into the template.

Another step may be to fine tune settings. The controller12may suggest templates, but the user10may also fine-tune the automatically recorded settings. Alternatively or additionally the user10may modify a recording by adding and/or removing steps manually

In the example ofFIG. 3the user10switches on and off four lights4. A user may do this by changing the state of all those lights4at once, or one by one. In this fine-tuning stage the user10may combine the four individual actions into a single action, such that when he or she presses the button5the four lights switch on together, instead of one by one. The user10may also delete erroneous recording events at this point in time.

To add temporal qualities, the user10may later add pauses and delays to the template. This would for example allow the user to make a ‘delayed off-switch’, by adding a pause into the template after pressing a button5.

FIG. 4shows an example of how the user10may fine tune the settings. In this example the user10combines the four individual commands into a single command to control the four lights4as a group (instead of one-by-one). In other embodiments this may be done automatically if the controller12has knowledge that the four lights are often controlled as a group, or the user during the recording phase controlled the lights as a group.

Additionally, the controller12may notice that the second sequence of actions contains the same four lights4, only their states are different. It may therefore suggest to the user10to also group those lights. The user10may also do this himself.

As a further optional step, the user10may add state information. Here, in addition to fine-tuning the recorded settings, the user10can also enhance the recorded settings by adding conditional information about the state the system should be in. This could be (but is not limited to): time of day, or specific light state (on/off).

With regard to the state information, in embodiments the controller12may also add automatically computed state information. For example, since the controller12knows the full sequence of recording, it knows which devices4,5,6are part of the intended behavior. It can check commonalities in the states of each device. For example, it may find that when the button5was pressed the first time, all the lights4were off. It adds this as a state condition to the template. When the button was pressed the second time it finds that all lights were on (but not necessarily on the same color). It can automatically add these states to the template as is shown inFIG. 5.

The user may also add state information him- or herself, for example about states that are difficult for the controller12to determine itself, such as time of the day. SeeFIG. 6.

With the above-described process it is also possible to create more advanced behaviors. For example, the user10could create functionality which combines a sensor6and a switch5. E.g. during the recording phase, the user10may perform the following actions:Enter the room3—motion sensor6goes to trueTurn on the lights in the room3Press ‘on’ button of a smart dimmer switch5Activate a lighting scene (e.g. “Concentrate”) in the room3Press the ‘on’ button of the smart dimmer switch5Activate another scene (e.g. “Relax”) in the room3Leave the room—motion sensors goes to falseTurn off the lights.

This will create a template whereby the user10can toggle between scenes (Concentrate and Relax) when he is in a given room3and presses the on-button of the switch5as the system automatically detects the devices that take part in the template and the sequence of actions.

In embodiments, the process of creating a template is as follows.Record a sequence of actions fully.Retrieve the individual devices4,5,6that take part in the template.Each individual device knows its type and its capabilities.Classify each recorded event as ‘trigger’ or ‘action’Input devices such as switches5or sensors6will typically be classified as ‘triggers’.Output devices such as luminaires4or lamps will typically be classified as ‘actions’.For each classified ‘trigger’ evaluate all the participating devices and find commonalities in their states. When the states remain stable over several recorded events, it may be added as state condition. For example: a sensor has motion ‘true’ for part of the sequence. It is likely that all actions that happened while the motion sensor is set to ‘true’ should only happen when the motion sensor is set to ‘true’.Present the outcomes to the user10in a graphical user interface14allowing him or her to adjust the settings.Additionally, in embodiments, since the controller12knows the types of the devices that are used in the template, and the sequence of actions, it can suggest templates that are the same, or similar as the one that the user10recorded. These templates may be stored in a large database.

In the case where the controller12proposes templates from a database, the search can be optimized by considering the additional information in the system. For example, if the user10sets up behavior for a living room3athe controller12can propose templates to him or her that are typically used in a living room.