Update!
When I originally open sourced Colorpicker, it was a beautiful MVP based on some really nasty legacy code.
I haven't had the time to focus on this project extensively, but over the last year I've made a lot of important improvements and wanted to discuss them briefly in this forum.
I still have several longer term goals for this project, such as eliminating the need for the Arduino entirely so that anyone can run the client on any computer (with an emphasis on low-memory and disk space cases for usage with a Raspberry Pi, Beaglebone, or other cheap computer).
I'm going to cover six new features added, but there are many more improvements I've made that you can see more about on Github.
Gratuitous Video Demo
Overhall Client and Elimination of the halo.pl PERL script
To frame why this script existed in the first place, I want to explain a bit about the evolution of this project. My roommate has skills more suited to hardware, and had built an initial implementation using just Arduino code. In order to address the lights on the fly, he began building a web-based UI. This web-based UI worked in conjunction with a PERL script that converted color input in the browser into UART instructions.
When I started building this colorpicker server/client, I inherited all of the source code, and tapping into the already-functional PERL script seemed to be the quickest approach to communicate with the Arduino via UART.
As I have developed the app more, I've desired more and more to eliminate the PERL artifact and move all business logic into pure Javascript. These pull requests demonstrate moving the entire application stack to Javascript, meaning that even my instructions to virtual devices in linux are now called via Node. Cool.
If you want to see the gorey details, the two pull requests linked in the header of this subsection represent the work to move to full-stack Javascript. The meat of the change here is actually quite simple. Instead of writing our color data to a text file, as the previous PERL script did, we now write our color instructions via UART at the /dev/tty01 device on the client linux box.
Color Generators
These are two "nice to have" features, but are useful and cool nonetheless. The first is a "Hue Complement" button. This button requires you have saved at least 1 color into a bank. It generate the bitwise complement to that color, and generate a "hue ramp" between the two colors. Make rainbows, yo!
The second is simple. It turns all the lights white. Epic #fff ambient lighting, yo!
Saved Colors
This feature introduces the ability to save sets of colors into a Redis cache, and bring them up again in the future with a single click. It required a lot of work across the stack, including building a UI to hide saved colors "behind" the main application window, as well as implementing APIs that wrap the server's interaction with Redis. You can see these APIs in the /api/v1/colors routes.
Basic HTTP Authentication
With this change, you can set environment variables containing a username and password, thusly protecting your precious colorpicker from joker neighbors who like to control your lights from the street below your apartment!
Test Suite + CI
This is self explanatory for the most part, but by god we've tested it! The server and client-side tests both use mocha + chai; the client-side tests use PhantomJS and Karma as a headless browser to test the Backbone.js app.
- https://github.com/Lordnibbler/colorpicker-server/pull/16
- https://github.com/Lordnibbler/colorpicker-server/pull/19
Scheduler
This feature introduces a binary /bin/scheduler which can be executed by a background worker. It reads from two environment variables to determine what time to turn the colorpicker on or off, if at all! This can be useful if, for instance, you want to have the colorpicker turn off at midnight and turn back on to a random saved color combination around sunset the next day.
More
Want to know more about how to set up a colorpicker of your own? Have questions about the source code? Comment below and I'll answer!