My Wake-Up Settings
-My wake-up settings
+
My wake-up is scheduled for 7:00 to gradually brighten the lights with
a half-hour fade-in each weekday. I also toggled on the setting to
@@ -42,11 +42,21 @@ automatically turn the lights off at 9:00.
Finding things on the bridge
+-Wake up is kicked off at 6:30 with a schedule: +The most natural starting point is to check the schedules. Right off +the bat, I find what I'm after:
+The schedule
+GET http://bridge/api/${username}/schedules/1@@ -73,9 +83,40 @@ Wake up is kicked off at 6:30 with a schedule:
-This schedule triggers a sensor:
+This is a recurring schedule item that runs every weekday at 6:30. We
+can tell this by looking at the localtime field. From the
+documentation on time patterns, we can see that it's a recurring time
+pattern specifying days of the week as a bitmask, and a time (6:30).
0MTWTFSS |
+
01111100 (124 in decimal) |
+
+Since this schedule is enabled, we can be assured that it will run,
+and in doing so, will issue a PUT to a sensors endpoint, setting a
+flag to true.
+
… triggers the sensor
+GET http://bridge/api/${username}/sensors/2@@ -103,9 +144,17 @@ This schedule triggers a sensor:
-A rule is triggered by this sensor updating: +The sensor is what's really setting things in motion. Here we've got +a generic CLIP flag sensor that is triggered exclusively by our +schedule. Essentially, by updating the flag state, we trigger the +sensor.
+… triggers a rule
+GET http://bridge/api/${username}/rules/1@@ -148,8 +197,21 @@ A rule is triggered by this sensor updating:
-The bedroom group is set to the following scene, which turns on the
-lights at minimum brightness:
+Now things are happening. Looking at the conditions, we can see that
+this rule triggers when the wakeup sensor updates, and its flag is set
+to true. When that happens, the bridge will iterate through its
+rules, find that the above condition has been met, and iterate through
+each of the actions.
+
… which sets the scene
+
+The bedroom group (/groups/1 in the rule's action list) is set to
+the following scene, which turns on the lights at minimum brightness:
… and schedules the transition
+
-Another schedule is enabled by the rule, which fires one minute after
-its creation:
+Another schedule (/schedules/2 in the rule's action list) is enabled
+by the rule.
-That schedule sets another scene, which transitions the lights to full
-brightness over the next 29 minutes (1740 seconds).
+This schedule is a bit different from the one we saw before. It is
+normally disabled, and it's time pattern (in localtime) is
+different. The PT prefix specifies that this is a timer which
+expires after the given amount of time has passed. In this case, it is
+set to one minute (the first 60 seconds of our wake-up will be spent
+in minimal lighting). Enabling this schedule starts up the timer. When
+one minute is up, another scene will be set.
+This one, strangely, is applied to group 0, the meta-group including
+all lights, but since the scene itself specifies to which lights it
+applies, there's no real problem with it.
+
… to a fully lit room
+GET http://bridge/api/${username}/scenes/gXdkB1um68N1sZL@@ -274,6 +357,17 @@ brightness over the next 29 minutes (1740 seconds).
+This scene transitions the lights to full brightness over the next 29
+minutes (1740 seconds), per the specified transitiontime (which is
+specified in deciseconds).
+
… which will be switched off later.
+Finally, an additional rule takes care of turning the lights off and the wake-up sensor at 9:00 (Two and a half hours after the initial @@ -325,5 +419,33 @@ triggering of the sensor). }
+Unlike the first rule, this one doesn't trigger immediately. It has an
+additional condition on the sensor state flag using the special ddx
+operator, which (given the timer specified) is true two and a half
+hours after the flag has been set. As the schedule sets it at 6:30,
+that means that this rule will trigger at 9:00, turn the lights off in
+the bedroom, and set the sensor's flag to false.
+