code « My Site/Blog
Untitled Document


Smart Outlet

So this project has been on the backlog for quite some time now and I’ve finally been able to put in some work. The first reason it’s been hard to post things is because my day job keeps me quite busy, the second reason that this project, in particular, took so long is because I’m scared of mains. However, with that being said, it’s also one of the projects I’ve been eager to start.

In an age where technology is more advanced than ever, we’re still stuck with a lot of dumb devices. My phone can take 1080p video, browse the internet, and can even be used to pay for things, yet I can’t turn on a light or the AC without having to push a physical switch. Now those may seem like silly, even solved (Philips Hue) problems however, they touch on a larger issue, which is energy. I set out to solve two problems with this project: how we interact with it, and how to leverage new infrastructure to make those interactions more efficient.

IMG_0667I started with a standard outlet. Adding relays allowed for simple on/off control of devices that have hard power switches (ones that physically stay opened or closed). Current monitoring is provided by a ACS712 series chip. A Bluetooth module was added for wireless communication, as well as an RFID reader for additional interaction.

IMG_0664Once the infrastructure is there, a whole new level of automation can be reached. Lights and coffee that turn on in the morning (set from the time on your phone’s alarm), and turn off after you’ve left (phone drops off the list of Bluetooth devices in the area). If you’re worried your pet might get too hot during the day, you could schedule your AC to turn on periodically to keep your apartment cool. By gathering data on how much power your electronics draw over time, you could schedule energy intensive tasks to take advantage of off-peak pricing, or just create a bunch of interesting graphs.

This project is definitely in its early stages and it’s something I’d really like to put more time into. You can expect more updates and an in-depth write-up in the future.

Caught in the Rain


Weather has never really been a concern of mine in the past. If I got caught out in the rain I usually just wait it out or run through until I could find shelter. However, when you’re commuting to work at an office building you really can’t show up late or soaking wet just because you didn’t know it was supposed to rain. This is where the motivation for this project comes from. Now those of you who are, perhaps, more collected might be wondering why I don’t just check my phone every morning like a normal person. Those of you, perhaps, do not realize the small miracles that must occur each morning for me to walk out the door, on time, with all the necessary belongings for the day.

I wanted something simple. I wanted to know weather (whether) or not the forecast called for rain during any of the hours of the day where I would most likely be walking outside (say 8-9 in the morning and 5:30-6:30 in the evening). I wanted to know as soon as I got up, in a very simple and intuitive way that even my morning grogginess couldn’t obscure.

This project gave me the perfect opportunity to use the Intel Galileo I’ve had sitting under my desk. While it definitely could have been done with an Arduino, the Galileo happens to have a built in ethernet jack and I didn’t have an ethernet shield lying around (or Arduino).

I started with the data. I needed easy access to some simple weather info which Yahoo happens to provide in xml. It’s pretty basic and doesn’t really offer the hourly data I wanted but, it’s a start. The Galileo is running a javascript environment called galileo-io which is based on the Johnny-Five Arduino framework (essentially javascript for the arduino). Getting the data I want is quite simple. In this case I’m only concerned with one value, the first instance of code in the yweather:forecase tag (the present forecast). Yahoo provides a simple guide which explains each code, making it easy to create a binary situation: rain/thunderstorms bad, everything else-whatever. I created a simple list of values that I could compare the given code to that, if matched, would indicate some sort of rain. Adding a simple delay() then allows me to have this GET request run every day, making sure that the Galileo will always have relevant data.

Pretty straight-forward so far, and the hardware side is no different. Having essentially narrowed this down to a two-case problem (rain or no rain) I could get away with having a single LED turning on or off. But that’s not really what I’m going for. My hope it to connect it to the audio controller that currently controls the LED strips in my room, in order create a much more immersive and dynamic visual (think flashing lights or gentle fades for thunderstorms and showers). I, unfortunately, don’t have access to my room right now but I’ll be sure to post an update once I have something more visually interesting to show.

More On GrammerPolice

I originally started writing this post in November before the CS Fair I was presenting at however, got caught up in school work. The plugin actually ended up winning an award as the best independent project, which caught me completely by surprise (I’ll probably talk about the fair in another post). I just thought I’d go into a little more depth about the problems I faced when designing the plugin and ways in which I tried to overcome them (original post can be found here).

One of the first problems I ran into was where to store all the information generated by the plugin (errors/ corrections). A coworker at the time recommended I check out a service called Firebase, which happened to be a free, easy-to-use, scalable backend. I set up a free account in a few minutes, went through a couple of tutorials, and ended up with a database to test the plugin.

The next issue I had was how to reliably access and store data from static web pages. Say for example you have the following sentence:

The quick brown fox jumped over the lazy dog

For the sake of simplicity let’s just imagine that such a sentence is contained within <p> tags on a webpage. Say the user of the app needs to highlight the word “the”. Right away you can see that you have no idea which “the” I am actually referring to. Solving this problem and more complicated iterations of it (dynamic pages) was probably the biggest challenge I faced in designing the script.

My solution was to include an index to the word from the beginning of the sentence, which I defined either as the first sentence contained within a tag or by the “.” character. Assuming we wanted to choose the second “the”, we would store an index value of six (starting from 0). Thus upon returning to the sentence we could tell our script to highlight the sixth word.

The next, more complicated, example would be if you had two paragraphs with similar content. Worst case scenario would look something like this:

<p>The quick brown fox jumped over the lazy dog</p>

<p>The quick brown fox jumped over the lazy dog</p>

As you can see, another reference is then needed in order to be able to address the correct word. I decided to add an html5 custom data attribute to each <p> tag hashed out from the website URL. This injection was accomplished using jQuery and simple onload function that appended the custom attribute onto specified containers (h1, h2, p, ect.) For the example above that would have looked a little something like this:

<p data-gp=”domain1″>The quick brown fox jumped over the lazy dog</p>

<p data-gp=”domain2″>The quick brown fox jumped over the lazy dog</p>

The domain would be the URL of the webpage while the last number indicates the index of the <p> tag relative to the beginning of the page. Thus making it possible to address and access any word on a given page, while still (hopefully) being able to accommodate small changes in content. I chose to use periods to break up paragraphs as I thought it more likely to have a sentence edited for correctness rather than be outright deleted. That way even if a portion of a sentence was deleted the plugin would still, hopefully, be able to navigate to the correct location. From there, the only difference between accessing data and storing it was the inclusion of one extra method, which would return the ID of the parent element.

The last problem was storing enough information that the plugin would be able to reliably return to a page and locate the correct text. This was accomplished by creating a new data reference every time the user clicked the plugin’s submit button. The reference would include the URL of the current page, an error object (the error, and necessary references), and the user submitted correction. Therefore, when a user visits a webpage the plugin will first check to see if that URL is contained within the database. If it is, the plugin will then inject the html references highlight the errors with the stored information.

Overall, the design of the plugin is much more suited to handling static content, with aspects of the dynamic handling being slightly abstracted. For instance, issues arise if new containers are introduced, or if content is edited to a point that the references can no longer reliably point to the text they should. These are just a few of the bugs I would like to work on in the future.

I really enjoyed working on this project. It happened to be one of my first, involved, experience with JavaScript and any sort of databasing and was a great learning experience. I have far more work planned for the plugin than what I’ve completed as this is definitely one of the projects I’d like to see through to deployment. Please do not hesitate to contact me with any questions or comments you may have.



Mockups of the plugin in action (the floating text parts)

  • December 26th, 2013
  • posted in code
  • no comments