github/correl.github.io
1
0
Fork 0
mirror of https://github.com/correl/correl.github.io.git synced 2024-12-29 11:09:24 +00:00
Code Issues Projects Releases Packages Wiki Activity

[draft] continue writing hue wake-up

Browse source
This commit is contained in:
Correl Roush 2018-03-13 16:01:56 -04:00
parent 9295ca4544
commit 77dfe8a5d1
2 changed files with 210 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

146
_drafts/2018-03-13-hue-wake-up.html
View file

@ -28,9 +28,9 @@ Information on getting access to a Hue bridge to make REST API calls
to it can be found in the <a href="https://www.developers.meethue.com/documentation/getting-started">Hue API getting started guide</a>. to it can be found in the <a href="https://www.developers.meethue.com/documentation/getting-started">Hue API getting started guide</a>.
</p> </p>
<div id="outline-container-org3991407" class="outline-2"> <div id="outline-container-org00a0920" class="outline-2">
<h2 id="org3991407">My Wake-Up Settings</h2> <h2 id="org00a0920">My wake-up settings</h2>
<div class="outline-text-2" id="text-org3991407"> <div class="outline-text-2" id="text-org00a0920">
<p> <p>
My wake-up is scheduled for 7:00 to gradually brighten the lights with 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 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.
<img src="/images/Screenshot_20180313-131855.png" alt="nil"/> <img src="/images/Screenshot_20180313-131858.png" alt="nil"/> <img src="/images/Screenshot_20180313-131855.png" alt="nil"/> <img src="/images/Screenshot_20180313-131858.png" alt="nil"/>
</p> </p>
</div> </div>
</div>
</div>
<div id="outline-container-orgc0f4909" class="outline-2">
<h2 id="orgc0f4909">Finding things on the bridge</h2>
<div class="outline-text-2" id="text-orgc0f4909">
<p> <p>
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:
</p> </p>
</div>
<div id="outline-container-org8cf23dd" class="outline-3">
<h3 id="org8cf23dd">The schedule</h3>
<div class="outline-text-3" id="text-org8cf23dd">
<div class="org-src-container"> <div class="org-src-container">
<pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/schedules/1</span> <pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/schedules/1</span>
</pre> </pre>
@ -73,9 +83,40 @@ Wake up is kicked off at 6:30 with a schedule:
</div> </div>
<p> <p>
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 <code>localtime</code> field. From the
documentation on <a href="https://www.developers.meethue.com/documentation/datatypes-and-time-patterns#16_time_patterns">time patterns</a>, we can see that it's a recurring time
pattern specifying days of the week as a bitmask, and a time (6:30).
</p> </p>
<table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">
<caption class="t-above"><span class="table-number">Table 1:</span> Unraveling the weekday portion</caption>
<colgroup>
<col class="org-left" />
</colgroup>
<tbody>
<tr>
<td class="org-left"><code>0MTWTFSS</code></td>
</tr>
<tr>
<td class="org-left"><code>01111100</code> (124 in decimal)</td>
</tr>
</tbody>
</table>
<p>
Since this schedule is enabled, we can be assured that it will run,
and in doing so, will issue a <code>PUT</code> to a sensors endpoint, setting a
flag to true.
</p>
</div>
</div>
<div id="outline-container-orga693028" class="outline-3">
<h3 id="orga693028">&#x2026; triggers the sensor</h3>
<div class="outline-text-3" id="text-orga693028">
<div class="org-src-container"> <div class="org-src-container">
<pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/sensors/2</span> <pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/sensors/2</span>
</pre> </pre>
@ -103,9 +144,17 @@ This schedule triggers a sensor:
</div> </div>
<p> <p>
A rule is triggered by this sensor updating: The sensor is what's <i>really</i> setting things in motion. Here we've got
a <a href="https://www.developers.meethue.com/documentation/supported-sensors#clipSensors">generic CLIP flag sensor</a> that is triggered exclusively by our
schedule. Essentially, by updating the flag state, we trigger the
sensor.
</p> </p>
</div>
</div>
<div id="outline-container-org826fcd2" class="outline-3">
<h3 id="org826fcd2">&#x2026; triggers a rule</h3>
<div class="outline-text-3" id="text-org826fcd2">
<div class="org-src-container"> <div class="org-src-container">
<pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/rules/1</span> <pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/rules/1</span>
</pre> </pre>
@ -148,8 +197,21 @@ A rule is triggered by this sensor updating:
</div> </div>
<p> <p>
The bedroom group is set to the following scene, which turns on the Now things are happening. Looking at the conditions, we can see that
lights at minimum brightness: this rule triggers when the wakeup sensor updates, and its flag is set
to <code>true</code>. 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.
</p>
</div>
</div>
<div id="outline-container-orgd3092c6" class="outline-3">
<h3 id="orgd3092c6">&#x2026; which sets the scene</h3>
<div class="outline-text-3" id="text-orgd3092c6">
<p>
The bedroom group (<code>/groups/1</code> in the rule's action list) is set to
the following scene, which turns on the lights at minimum brightness:
</p> </p>
<div class="org-src-container"> <div class="org-src-container">
@ -192,10 +254,15 @@ lights at minimum brightness:
} }
</pre> </pre>
</div> </div>
</div>
</div>
<div id="outline-container-orgf293374" class="outline-3">
<h3 id="orgf293374">&#x2026; and schedules the transition</h3>
<div class="outline-text-3" id="text-orgf293374">
<p> <p>
Another schedule is enabled by the rule, which fires one minute after Another schedule (<code>/schedules/2</code> in the rule's action list) is enabled
its creation: by the rule.
</p> </p>
<div class="org-src-container"> <div class="org-src-container">
@ -226,10 +293,26 @@ its creation:
</div> </div>
<p> <p>
That schedule sets another scene, which transitions the lights to full <i>This</i> schedule is a bit different from the one we saw before. It is
brightness over the next 29 minutes (1740 seconds). normally disabled, and it's time pattern (in <code>localtime</code>) is
different. The <code>PT</code> 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.
</p> </p>
<p>
This one, strangely, is applied to group <code>0</code>, the meta-group including
all lights, but since the scene itself specifies to which lights it
applies, there's no real problem with it.
</p>
</div>
</div>
<div id="outline-container-org4ad1a9b" class="outline-3">
<h3 id="org4ad1a9b">&#x2026; to a fully lit room</h3>
<div class="outline-text-3" id="text-org4ad1a9b">
<div class="org-src-container"> <div class="org-src-container">
<pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/scenes/gXdkB1um68N1sZL</span> <pre class="src src-http"><span style="color: #5fafd7;">GET</span> <span style="color: #ffd700;">http://bridge/api/${username}/scenes/gXdkB1um68N1sZL</span>
</pre> </pre>
@ -274,6 +357,17 @@ brightness over the next 29 minutes (1740 seconds).
</pre> </pre>
</div> </div>
<p>
This scene transitions the lights to full brightness over the next 29
minutes (1740 seconds), per the specified <code>transitiontime</code> (which is
specified in deciseconds).
</p>
</div>
</div>
<div id="outline-container-orgbdc2c15" class="outline-3">
<h3 id="orgbdc2c15">&#x2026; which will be switched off later.</h3>
<div class="outline-text-3" id="text-orgbdc2c15">
<p> <p>
Finally, an additional rule takes care of turning the lights off and 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 the wake-up sensor at 9:00 (Two and a half hours after the initial
@ -325,5 +419,33 @@ triggering of the sensor).
} }
</pre> </pre>
</div> </div>
<p>
Unlike the first rule, this one doesn't trigger immediately. It has an
additional condition on the sensor state flag using the special <code>ddx</code>
operator, which (given the timer specified) is true <b>two and a half
hours after</b> 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 <code>false</code>.
</p>
</div>
</div>
</div>
<div id="outline-container-org8708191" class="outline-2">
<h2 id="org8708191">Where to go from here</h2>
<div class="outline-text-2" id="text-org8708191">
<p>
The wake-up config in the phone app touched on pretty much every major
aspect of the Hue bridge API. Given the insight I now have into how it
works, I can start constructing my own schedules and transitions, and
playing with different ways of triggering them and even having them
trigger each other.
</p>
<p>
If I get around to building my rolling sunrise, I'll be sure to get a
post up on it :)
</p>
</div> </div>
</div> </div>

86
_drafts/2018-03-13-hue-wake-up.org
View file

@ -23,7 +23,7 @@ customizations.
Information on getting access to a Hue bridge to make REST API calls Information on getting access to a Hue bridge to make REST API calls
to it can be found in the [[https://www.developers.meethue.com/documentation/getting-started][Hue API getting started guide]]. to it can be found in the [[https://www.developers.meethue.com/documentation/getting-started][Hue API getting started guide]].
* My Wake-Up Settings * My wake-up settings
My wake-up is scheduled for 7:00 to gradually brighten the lights with 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 a half-hour fade-in each weekday. I also toggled on the setting to
automatically turn the lights off at 9:00. automatically turn the lights off at 9:00.
@ -32,7 +32,12 @@ automatically turn the lights off at 9:00.
[[img:Screenshot_20180313-131855.png]] [[img:Screenshot_20180313-131858.png]] [[img:Screenshot_20180313-131855.png]] [[img:Screenshot_20180313-131858.png]]
#+END_CENTER #+END_CENTER
Wake up is kicked off at 6:30 with a schedule: * Finding things on the bridge
The most natural starting point is to check the schedules. Right off
the bat, I find what I'm after:
** The schedule
#+BEGIN_SRC http #+BEGIN_SRC http
GET http://bridge/api/${username}/schedules/1 GET http://bridge/api/${username}/schedules/1
@ -58,7 +63,20 @@ Wake up is kicked off at 6:30 with a schedule:
} }
#+END_SRC #+END_SRC
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 [[https://www.developers.meethue.com/documentation/datatypes-and-time-patterns#16_time_patterns][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).
#+CAPTION: Unraveling the weekday portion
| =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
#+BEGIN_SRC http #+BEGIN_SRC http
GET http://bridge/api/${username}/sensors/2 GET http://bridge/api/${username}/sensors/2
@ -85,7 +103,12 @@ This schedule triggers a sensor:
} }
#+END_SRC #+END_SRC
A rule is triggered by this sensor updating: The sensor is what's /really/ setting things in motion. Here we've got
a [[https://www.developers.meethue.com/documentation/supported-sensors#clipSensors][generic CLIP flag sensor]] that is triggered exclusively by our
schedule. Essentially, by updating the flag state, we trigger the
sensor.
** ... triggers a rule
#+BEGIN_SRC http #+BEGIN_SRC http
GET http://bridge/api/${username}/rules/1 GET http://bridge/api/${username}/rules/1
@ -127,8 +150,16 @@ A rule is triggered by this sensor updating:
} }
#+END_SRC #+END_SRC
The bedroom group is set to the following scene, which turns on the Now things are happening. Looking at the conditions, we can see that
lights at minimum brightness: 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:
#+BEGIN_SRC http #+BEGIN_SRC http
GET http://bridge/api/${username}/scenes/7GJer2-5ahGIqz6 GET http://bridge/api/${username}/scenes/7GJer2-5ahGIqz6
@ -170,8 +201,9 @@ lights at minimum brightness:
} }
#+END_SRC #+END_SRC
Another schedule is enabled by the rule, which fires one minute after ** ... and schedules the transition
its creation: Another schedule (=/schedules/2= in the rule's action list) is enabled
by the rule.
#+BEGIN_SRC http #+BEGIN_SRC http
GET http://bridge/api/${username}/schedules/2 GET http://bridge/api/${username}/schedules/2
@ -199,8 +231,19 @@ its creation:
} }
#+END_SRC #+END_SRC
That schedule sets another scene, which transitions the lights to full /This/ schedule is a bit different from the one we saw before. It is
brightness over the next 29 minutes (1740 seconds). 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
#+BEGIN_SRC http #+BEGIN_SRC http
GET http://bridge/api/${username}/scenes/gXdkB1um68N1sZL GET http://bridge/api/${username}/scenes/gXdkB1um68N1sZL
@ -245,6 +288,11 @@ brightness over the next 29 minutes (1740 seconds).
} }
#+END_SRC #+END_SRC
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 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 the wake-up sensor at 9:00 (Two and a half hours after the initial
triggering of the sensor). triggering of the sensor).
@ -293,3 +341,21 @@ triggering of the sensor).
] ]
} }
#+END_SRC #+END_SRC
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=.
* Where to go from here
The wake-up config in the phone app touched on pretty much every major
aspect of the Hue bridge API. Given the insight I now have into how it
works, I can start constructing my own schedules and transitions, and
playing with different ways of triggering them and even having them
trigger each other.
If I get around to building my rolling sunrise, I'll be sure to get a
post up on it :)