Supported sensors:
- Philips Tap switch
- Philips dimmer
- Philips motion sensor
- External input via a CLIP sensor (e.g., bound Eltako Enocean switches and door/window contacts)
A configuration is a list of dictionaries, each dictionary defining behavior for a sensor.
Each dictionary in the configuration must have value for key type
defining sensor type:
state
for a virtual sensor with state (e.g., for multi-click switches)switch
for a Philips Tap switch or dimmerexternal
for external inputcontact
for a virtual contact sensor fed by external input actionsmotion
for motion sensor
Example:
{
"type": "state",
"name": "My state",
"group": "My group" # only needed for @off timeout
}
State sensor is used to store the state of a switch. One state sensor can be used to store two
states, e.g., positive for cycling through scenes on on
button and negative for toggling between
off and nightlight scene on off
button.
State virtual sensor creates one CLIP sensor and optionally one rule to reset the sensor.
Example:
{
"type": "switch",
"name": "My switch",
"group": "My group",
"bindings": {
"tl": { "type": "scene", "configs": [ {"scene": "My scene"} ] },
"bl": { "type": "scene", "configs": [ {"scene": "off"} ] },
"tr": { "type": "dim", "value": 50, "tt": 5 },
"br": { "type": "dim", "value": -50, "tt": 5 }
}
}
This example defines rules for switch My switch
which operate on group My group
. Individual
scene actions may operate on different groups, later more on that. This particular example is
for a Philips Tap switch whose sender was inserted into an Eltako frame and mounted on the wall.
It defines actions for individual buttons by symbolic names instead of button IDs.
Following symbolic names are supported:
1
,2
,3
and4
for original Hue Tap Switch,top-left
,bottom-left
,top-right
andbottom-right
ortl
,bl
,tr
andbr
for Hue Tap Switch sender built into Eltako switch frame and mounted on a wall,on
,on-hold
,on-release
,on-hold-release
,off
,off-hold
,off-release
,off-hold-release
,brighter
,brighter-hold
,brighter-release
,brighter-hold-release
,darker
,darker-hold
,darker-release
,darker-hold-release
,off
,off-hold
,off-release
andoff-hold-release
for Hue Dimmer,on
,on-hold
,on-release
andon-hold-release
for Hue Smart Button.
Each binding creates by default one rule, except multi-scene and toggle bindings (see later).
Example:
{
"type": "external",
"state": "My state",
"name": "My switch",
"group": "My room",
"bindings": {
"11": {
"type": "scene",
"configs": [
{"scene": "Night"},
{"scene": "Day"},
{"scene": "Other"}
],
"times": {
"T07:00:00/T20:00:00": 2, # day
"T20:00:00/T07:00:00": 1 # night
},
"reset": "off"
},
"12": {
"type": "scene",
"value": "Nightlight",
"timeout": "00:20:00",
"action": "toggle"
}
}
}
This a bit more complicated example shows the usage of external input. It is very similar to switch configuration, but instead of button IDs we have values which are set from outside. Values 0 and 1 are reserved (0 for boot time and 1 for no action).
External input uses CLIP state sensor named ExternalInput
. If such a sensor doesn't exist, it will be created.
Since this particular example uses multi-state buttons, we need a state sensor to store the current
state of the switch to detect multiple presses. You can see that for input 11
, we have three scenes
and two time ranges. When no state is set, then the initial state is chosen based on the time range,
otherwise first scene is used. For input 12
, we have a toggle scene. More on this in action types.
This scene resets the state to negative value, so turning on the light will use proper time-based scene.
In order to differentiate between light on and nightlight, an additional rule is needed to reset
the sensor state when the light is turned off and to use sensor state instead of light group on state
to detect that a first press of the button was done. This is indicated by using flag "reset": "off"
for the binding of the on button (which normally uses light group on state to determine whether to
trigger the initial action or follow-up action). Note: the additional rule to reset state is really
needed in case when the light was turned off by the app or using a different action (e.g., all lights
off). This is cheaper than adding additional rule per state to detect light off situation.
Same as for switch sensor, each binding creates by default one rule, except multi-scene and toggle bindings (see later).
Example:
{
"type": "contact",
"name": "Bathroom door contact",
"bindings": {
"open": "1000",
"closed": "1001"
}
}
This type of virtual sensor uses only values 0/1 to indicate door or window is open/closed. As there
is no offer from Philips, we can only map external IDs to indicate contact is open or closed. This
example expects contact sensor to send external ID 1000
when the contact opens and ID 1001
when
the contact closes.
Contact sensor is extremely useful to disable motion sensor while door is closed. For example, bathroom motion sensor might have a timeout of 1 minute, but when someone is in the bathroom taking a shower, he doesn't want to do it in the dark. The contact sensor can be used to stop motion sensor from turning off the light.
Contact sensor creates one CLIP sensor and two rules.
External input can be fed to the Hue Bridge by any external system capable of posting an integer
value to the CLIP status sensor ExternalInput
(identified by its ID in the respective PUT request).
The author uses a companion project enocean_to_hue to map commands sent by Enocean switches to integer values and send them to the Hue bridge. Refer to the documentation of that project for more details.
As hardware, the author uses Eltako FT55R rocker switches and Eltako TF-FKB door/window contact to generate events, which are then processed by the aforementioned gateway. The advantage is that it's possible to exchange the actual Enocean hardware in those switches with the one in Philips Tap buttons, so you can install "reliable" ZigBee inserts into Eltako frames and mount them on the wall and install "less reliable" Enocean inserts into left-over Philips Tap enclosures.
Example:
{
"type": "motion",
"name": "Bathroom sensor",
"group": "Bathroom",
"timeout": "00:00:45",
"dimtime": "00:00:15",
"contact": "Bathroom door contact",
"state": "Bathroom switch state",
"bindings": {
"on": {
"type": "scene",
"configs": [ {"scene": "Bright"} ]
},
"off": {
"type": "off"
}
}
}
A motion sensor turns light on upon motion and off when no motion is detected for some time. A Philips motion sensor with given name must be registered on the bridge.
Actions specified for on
binding is executed when the sensor detect the motion. If no motion
is detected, then after a timeout specified by timeout
parameter the light for the group
is dimmed (currently hard-coded action). After further timeout specified using dimtime
parameter
(which defaults to 20 seconds) the light is turned on completely. If there is a motion detected
during dim time, the light is restored to full light and the timeout starts anew.
Binding for off
is optional and defaults to turning off the lights. Binding for on
is also
optional, if not specified, the lights won't be turned on automatically (just turned off).
Additionally, it's possible to specify bindings for dim
and recover
, which are called on
no motion timeout to dim the lights and to recover light states if motion is detected in the
dimmed state. They by default dim the light by 50% and recover state before dimming. Storing
the light state may wear off the flash memory in lamps quicker, so it's possible to specify
recover
binding, typically to the same action as on
action (this can be shortened by specifying
string "on"
as the action). If recover
action is specified, then dim
action will not save
light state. However, since most users will use "recover after power failure" mode for light
bulbs, the state is saved anyway, so there will most likely be no difference in Flash memory
wear when using additional scene to store light state before dimming.
If the optional state
is present, then the switch state sensor with this name will be reset before
turning light on or off.
Note: if using on
action for recover
, you need to pay attention to use "reset": "off"
flag
for your multi-state scene action for on
, since otherwise the action will do nothing - the
light is on from the point of view of the on rules.
Optionally, a contact sensor defined in the same configuration can be addressed using contact
parameter. When there is no motion detected shortly after closing the door, the light is turned
off, by default after 16 seconds (use closedchecktime
to override), by first dimming and then
turning it to off, similar to normal timeout handling. Else, it is kept on until the door is
open again (and then normal rules with timeout apply). In case there is no motion detected
initially by mistake (due to reaction time of non-motion detection) and the light dims, motion
in the room will restore the light and won't dim it again until the door is open. Optionally,
if the sensor breaks, a fallback timeout can be specified via closedtimeout
to turn light off
after specified time of no motion behind closed door. As already mentioned, in sum, this behavior
is extremely useful for bathrooms.
If a motion sensor is used with a switch, then turning off the light while motion is detected
would simply turn the light back on immediately. To prevent this, the motion sensor adds rules
to explicitly disable itself for some time (default 30 seconds, but it can be overridden using
parameter offtimeout
) when the light is turned off manually (by a switch, external action or
in the app).
Motion sensor creates one CLIP sensor to store sensor state and 6 rules for standard motion handling, 3 rules for integration with switches to properly handle manually turning light on or off and if a door contact is used, then additional 4 rules for handling door contact. I.e., depending on the configuration, up to 13 rules are used for a single motion sensor.
It is also possible to use multiple motion sensors for a room. Add sensors
parameter with the
list of sensor names to use. These sensors will be assigned to the group representing the room and
group's presence and light state will be used instead of the single motion sensor named by name
.
Note: if the motion sensor is disabled, then the rules won't trigger at all, including timeout after turning on the light. Reenabling the sensor reenables the rules. The only issue so far is a bug in Hue bridge which fails to process the no-presence rule if the light is already on and won't turn it off after a timeout. However, motion in front of the sensor or triggering any other rules for the sensor (e.g., manually turning off the light) will clean up the state and the sensor will work as expected.
For each binding, there must be an action specified. Currently, following actions are supported:
scene
- set scene (supports multi-scene and time-dependent scenes and toggle with scene)off
- turn a group of lights offlight
- turn a single light on, off or toggle its statedim
- dim up or down a groupredirect
- redirect to another action by setting value ofExternalInput
sensor
Note that it is also possible to specify a list of actions for a binding to execute multiple actions for a single binding (e.g., turn off light in multiple rooms and the like).
Example:
{
"type": "state",
"name": "My state"
},
{
"type": "switch",
"state": "My state",
"reset": "off",
"name": "My switch",
"group": "My room",
"bindings": {
"2": {
"type": "scene",
"configs": [
{"scene": "Night"},
{"scene": "Day"},
{"scene": "Other"}
],
"times": {
"T07:00:00/T20:00:00": 2, # day
"T20:00:00/T07:00:00": 1 # night
}
},
"1": {
"type": "scene",
"value": "Nightlight",
"timeout": "00:20:00",
"action": "toggle"
}
}
}
Scene action is the most powerful action available. It allows you to specify list of scenes using
configs
parameter and set of time ranges with scene index in optional times
parameter. In the
simplest case, there is just a single scene present and no state or times specified. For single
scene, instead of configs
with a single scene, you can also use parameter value
which names
a single scene.
When multiple scenes are specified, the scene to use depends on the state. Typically, the state is reset after some timeout, so when the action is repeated (e.g., light switched on), the first scene is selected. Multiple action triggers (e.g., multiple light switch presses) cycle through scenes in configuration.
A special scene off
is used to turn all lights in the group off. In case the entire scene action
should just turn lights off, you can also use action type off
instead.
If an optional times
parameter is specified, then instead of starting with the first scene,
the current time is compared against specified intervals and the scene at the associated index
is recalled (1-based, i.e., Night
scene in the above example has index 1). If there is no
time range for the current time, then no action is triggered.
Additional timeout
parameter can be specified for a configuration of the scene to turn off lights
after the specified timeout (unless another action was triggered).
If a scene is set "from the side" by a different switch, you can explicitly set state using
setstate
parameter in the binding, which sets the index of the scene configured by another
binding using multi-scene action with the same state
and group
parameters.
Scenes create one rule per scene, one rule to start default scene or per time range one rule to start default scene for the time range. I.e., the above example would create 5 rules for binding 2 and 3 rules for binding 1.
Each timeout to turn off lights in a specified scene after a timeout adds one additional rule.
In addition to normal time and count dependent scene scheduling, it is also possible to set
additional action using action
parameter. Currently, the only available action is toggle
to toggle the light state of a group by setting it to a specific scene if off or turning it
off if on.
Example:
{
"type": "switch",
"name": "Kitchen cabinet",
"bindings": {
"on": {
"type": "scene", # group action
"group": "Kitchen cabinet", # group to manage
"value": "Concentrate", # scene to set
"action": "toggle" # toggle between on/off states only (single config)
}
}
}
Example:
{
...,
"bindings": {
"on": {
"type": "scene",
"configs": [ {"scene": "Bright"} ]
},
"off": { "type": "off" }
}
}
Use action type off
to turn lights of the group off. This is shorthand for
{ "type": "scene", "configs": [ {"scene": "off"} ] }
.
Off action creates one rule.
Example:
{
"type": "external",
"name": "Kitchen switch",
"bindings": {
"22": { "type": "light", "light": "Kitchen cabinet", "action": "toggle" }
}
}
Light action defines one of the actions for a single light:
on
- turn the light onoff
- turn the light offtoggle
- toggle the state of the light (see example)
Currently, there is no possibility to specify the light color or intensity when turning it on.
On and off actions create one rule, toggle action creates two rules.
Example 1:
{
"type": "switch",
"name": "My switch",
"group": "My group",
"bindings": {
"tl": { "type": "scene", "configs": [ {"scene": "My scene"} ] },
"bl": { "type": "scene", "configs": [ {"scene": "off"} ] },
"tr": { "type": "dim", "value": 50, "tt": 5 },
"br": { "type": "dim", "value": -50, "tt": 5 }
}
}
This example shows how to configure a simple switch to use left rocker to turn the light on and off and the right rocker to increase and decrease brightness of the light.
Example 2:
{
"type": "switch",
"name": "My dimmer",
"group": "My group",
"bindings": {
"on": { "type": "scene", "configs": [ {"scene": "My scene"} ] },
"off": { "type": "scene", "configs": [ {"scene": "off"} ] },
**HueBridge.DIMMER_RULES
}
}
In this a bit more complex example you see configuration of a Philips dimmer. Instead of
explicitly configuring all rules for dimming up and down, simply add HueBridge.DIMMER_RULES
to the list of bindings for the dimmer. Then, it's sufficient to configure on
and off
actions.
Dim action creates one rule.
Example:
{ "type": "redirect", "value": "14" }
Redirect action is the simplest one - when the event fires, it simply sets ExternalInput
to the
specified value, which then triggers another event. This is useful for handling complex actions
of several switches in the same way. E.g., if you have two or more switches in the same room and
they should behave identically, you could configure them identically. But, if one of the buttons
has a complex action (e.g., multi-scene time-based action), then you can implement this action
once as external
with some ID and simply redirect buttons of all switches to the same action.
Redirect action creates one rule.
from hue import HueBridge
BRIDGE="192.168.xx.xx" # set your bridge IP here
API_KEY="xxxx" # set your API key here
CONFIG_LR = [
# Switches to manage
# Redirect to external actions, so we can use more than one switch
{
"type": "switch",
"name": "Livingroom switch",
"bindings": {
"tr": { "type": "redirect", "value": "14" },
"br": { "type": "redirect", "value": "12" }
}
},
# State for cycling the switch
{
"type": "state",
"name": "Livingroom state",
"timeout": "00:00:10"
},
# Actions for input - either external input or via the wall switch
{
"type": "external",
"state": "Livingroom state",
"name": "Livingroom switch",
"group": "Livingroom",
"bindings": {
"14": {
"type": "scene",
"configs": [
{"scene": "Evening"},
{"scene": "TV"},
{"scene": "Bright"},
{"scene": "Day"}
],
"times": {
"T07:00:00/T16:00:00": 4, # day
"T16:00:00/T07:00:00": 1 # evening
}
},
"12": {
"type": "scene",
"value": "Night",
"timeout": "00:20:00",
"action": "toggle"
},
# additional action to turn off kitchen light from the living room
"11": {
"type": "scene",
"group": "Kitchen",
"configs": [
{"scene": "off"}
]
}
}
}
]
CONFIG_WC = [
{
"type": "contact",
"name": "Bathroom door contact",
"bindings": {
"open": "1000",
"closed": "1001"
}
},
{
"type": "motion",
"name": "Bathroom sensor",
"group": "Bathroom",
"timeout": "00:00:45",
"dimtime": "00:00:15",
"contact": "Bathroom door contact",
"bindings": {
"on": {
"type": "scene",
"configs": [ {"scene": "Bright"} ]
},
"off": { "type": "off" }
}
}
]
if __name__ == '__main__':
h = HueBridge(BRIDGE, API_KEY)
h.configure(CONFIG_LR, "Livingroom")
h.configure(CONFIG_WC, "Bathroom")
This example shows two independent configurations for living room with multi-state scenes and for bathroom with motion sensor. Refer to a complex, documented example in hue_rule_generator.py for further real-world examples with detailed explanation in comments.