photo - cavorite

photo – cavorite

As our platform has matured (Light and Holiday share a common hardware and software platform), we’ve learned a few things. For example:

  • Apache is overkill on a small profile device like Holiday;
  • Python is wonderful but takes a long time to load – best to do it once;
  • 64 MB of RAM is enough, but not a lot;
  • It’s always better to let Linux do the work.

We touted the Light as the ‘LAMP with a LAMP stack’, which was true – and truly not the best fit for the profile of the platform. In the months of developing since then we’ve come up with some better ways of doing things.   So we have a slightly different stack – just as powerful, with the same logical components, but arranged in a profile more suitable to the resources and requirements of Holiday.

  • Linux – Arch Linux, which we’ve come to know and love;
  • IoTAS – Our Internet of Things Access Server, which provides all HTTP services;
  • SQLite – One of the most useful open source projects of all time;
  • Python – Still our favourite programming language at MooresCloud

Our LAMP stack has become a LISP stack (not to be confused with John McCarthy’s famous LISt Processing language).  Over the next weeks we’ll push IoTAS to our GitHub account, so you can pull it down and see how we’re working to implement the Holiday API. It’s a work-in-progress – as everything is at MooresCloud – but you’ll learn enough to write your own Holiday apps.

Holiday hardware at a glance


We’ve just announced Holiday by MooresCloud, our casual lighting solution for the Christmas Tree or anywhere else you want some fun, beautiful, connected, programmable lights — with a full REST API!

Holiday hardware features (incomplete list – minor edits 4/12/13):

  • 7 metre string of 50 ‘globes’ in opalescent diffusing shell
  • 1 meter runner, 6 meters of lights with 120mm spacings
  • Globes are full 24-bit color capable
  • Globes are individually addressable
  • Globes are removable and replaceable in case of failures! (hopefully in a future release)
  • iMX233 CPU running Arch Linux @ 454 Mhz
  • 64 MB DDR RAM
  • 2 GB 4 GB microSD – easily accessible & replaceable. 
  • Atmel ATmega328 microcontroller (drives the globes)
  • 3 buttons (mode / plus / minus)
  • USB with 802.11n WiFi adapter
  • Controller board is fully open hardware
  • 3A 5 VDC switching power supply (internationally compatible)

That’s very brief I know.  We’ll go into full details – and schematics and PCB layouts for the open hardware components. Because you know us – we love to share.

More soon.



photo - futursonic

photo – futursonic

It’s that time of year, when we all go to a lot of Holiday parties.  This evening I’ll be attending one – and I’ve decided to bring along Indigo, one of the three new battery-powered Lights.  I’ve written a small Python script that has connected a series of different apps to her tactile switch.  (Yes, the Light has a tactile switch in the front of its central opening.)

It’s not very complicated, and references the locations of specific programs in the file system – something that is not advisable and will be discouraged in release software, but was quick, dirty, and effective.  Here’s the code:



# Make the Light act like... a fun party device!


# Poll the tactile switch, when pressed, run a command.

# When pressed again, turn it off.  Go on to next command.


import subprocess, time, os

switch_gpio = """/sys/class/gpio/gpio0/value"""

ons = ["""/srv/http/cgi-bin/candle &""", """/srv/http/cgi-bin/flame &""",  """/srv/http/cgi-bin/sweep &""",

		"""/srv/http/cgi-bin/supersweep &""", """/srv/http/cgi-bin/placcel &""" ]

offs = ["""sudo killall candle; batsignal""", """sudo killall flame; batsignal""", """sudo killall sweep; batsignal""",

		"""sudo killall supersweep; batsignal""", """sudo killall placcel; batsignal""" ]

cmd_location = 0


def read_switch():


		val = subprocess.check_output(["cat", switch_gpio])

	except subprocess.CalledProcessError:

		print "CalledProcessError!"

		return False

	if val[:1] == "1":

		return False


		return True

def change_state(new_state):

	global cmd_location, MAX_CMD

	if (new_state):




		cmd_location = cmd_location + 1

		if (cmd_location > MAX_CMD):

			cmd_location = 0

if __name__ == '__main__':

	print cmd_location

	curr_state = False

	flip_flop = False

	while 1:

		switch_state = read_switch()

		#print switch_state

		if (curr_state == False) and (switch_state == True):

			if (flip_flop):

				flip_flop = False


				flip_flop = True


		curr_state = switch_state



When we first launched the Light on Kickstarter, we received mail from some folks who had what looked to be an interesting project – Cheerlights.  Basically it uses Twitter and some other server software to provide a universal ‘color’ for Internet-connected Christmas lights.  You can set a color on Cheerlights by posting a tweet with the hashtag #cheerlights somewhere in it, followed by a color name (white, warmwhite, red, orange, yellow, green, cyan, blue, purple, magenta).

The Cheerlights server listens for that sequence, then publishes the current color value in a JSON object accessible here. Devices can poll that object to learn the current Cheerlights color, and respond accordingly.

It’s all quite straightforward, and it was sitting on my to-do list until this week, when I started to give a real though to Christmas lights.  We’ll be doing a special holiday video and livestream a ‘change the color Light under the Christmas tree’ for folks to have a play, but on the way to that, I decided to have a look at Cheerlights, saw that it was going to be almost trivially easy to implement in our API, then wrote the whole thing in about 30 minutes  – in bash.

That’s right, we’ve implemented Cheerlights as a shell script. This means it’s quite fast – Python doesn’t need to load – and also very portable. It should run in some easily modified form on any *NIX box in the universe.

It does rely on two programs: cURL, which is considered part of the base package in most LINUX distributions, and jq, which is a command-line JSON parser in ‘C’, very fast, very flexible, and very powerful. As we do manipulate a lot of JSON data on the Light, we’ve compiled this package for the Light, and will ship it as part of the Light’s system software.

Here, in full, is the shell script:



# Set the Light to the current CheerLights color

# This is all done in bash. Because we can?


# Copyright (c) 2012, Mark D. Pesce

# Released under the MIT License.


# First grab the current CheerLights JSON thingy, then parse it to extract field1

# Which happens to be the current color value


color=`curl -s | jq .field1`

echo $color

# Now parse the color value which should be one of these fine colors maybe


case $color in

"red") echo "We got red"; export QUERY_STRING="color=0x80FF80"; /srv/http/cgi-bin/ajaxcolor


"cyan") echo "We got cyan"; export QUERY_STRING="color=0xFF80FF"; /srv/http/cgi-bin/ajaxcolor


"warmwhite") echo "We got warm white"; export QUERY_STRING="color=0xFFFFbF"; /srv/http/cgi-bin/ajaxcolor


"white") echo "We got white"; export QUERY_STRING="color=0xFFFFFF"; /srv/http/cgi-bin/ajaxcolor


"blue") echo "We got blue"; export QUERY_STRING="color=0x8080FF"; /srv/http/cgi-bin/ajaxcolor


"green") echo "We got green"; export QUERY_STRING="color=0xFF8080"; /srv/http/cgi-bin/ajaxcolor


"yellow") echo "We got yellow"; export QUERY_STRING="color=0xFFFF80"; /srv/http/cgi-bin/ajaxcolor


"magenta") echo "We got magenta"; export QUERY_STRING="color=0x80bfFF"; /srv/http/cgi-bin/ajaxcolor


"purple") echo "We got purple"; export QUERY_STRING="color=0x80FFFF"; /srv/http/cgi-bin/ajaxcolor


"orange") echo "We got orange"; export QUERY_STRING="color=0x90FF80"; /srv/http/cgi-bin/ajaxcolor


*) echo "We got no match at all"



The script needs to be run for every Cheerlights update, which could be done as a cron task, or it could be part of a background daemon.

Prototype hardware design files published

On the Schematics page, we’ve just published the hardware design files for the latest prototype, along with some additional details.  Keep in mind this is a work in progress.

And although this means you can now build a Light for yourself, if you add up the cost of sourcing small quantities of the individual components, and getting a small batch of PCBs made, you are easily up for several hundred dollars.  And you would still need to fabricate a nice semi-transparent enclosure – probably another few hundred dollars (at least), and unlikely to be as cool as our final industrial design.

Better just to back our Kickstarter and let us make one for you!  :-)

Why not Arduino?

photo – equinoxefr

This is something we hear a lot. People don’t understand why we’ve opted for such a powerful computer at the core of the Light.

Right at the very beginning, after my first meeting with Kean Maizels – who has since become our genius hardware designer – I was asked why I wanted such a powerful computer at the heart of the Light, when a simple microcontroller – a la Arduino – would be cheaper and easier to implement.

Here’s my response:

One of my guiding maxims in my work is a line from William Gibson: “The street finds its own use for things, uses the manufacturers never intended.”

The Light  is a general purpose computing device.  That is the reason the company is named MooresCloud.

It is intelligence: raw, unfiltered, capable of anything it puts its mind to.

That doesn’t mean there aren’t constraints.  There always are.

But the Light is perhaps best thought of as general purpose computing device with a very low-resolution display.

A ‘smart’ appliance isn’t smart enough.  A ‘smart’ appliance has a microcontroller capable of some pre-programmed tricks.  The Light should be capable of anything thrown at it, up to the limits of its CPU and memory.  Because we are creating a platform, we simply do not know, can not predict, and do not want to artificially limit the kinds of wild ideas people will implement on it. Uses the manufacturer never intended.

Creativity must be channeled, this is very true, and that means strong developer guidelines & resources, app review policies, and all of the subtle control-freakery that both Nintendo and Apple are famous for – without the underlying humourlessness.  Creativity is handmaiden to chaos, no doubt about it, and people will want devices that ‘just work’. This creates a natural and fertile tension both in the design of the device and in its use.

I would like us to pick our points of compromise carefully.  And the points upon which we will not compromise, because in them the whole of the design is reflected.  I believe this is one of those points.

That what I thought in the beginning of September, at the very start of this whole process.  I continue to believe it. Now, on the other side of the design process, I have some numbers to back it up. The difference in the Bill of Materials between an Arduino sophisticated enough to handle WiFi and a few basic REST commands, and our fully-fledged Linux ‘Lamp with a LAMP stack’?

Less than seven dollars.

Given this tiny differential in costs, the enormous gains in power and interiority – having a device that can think for itself, rather than just enact commands delivered by other devices – more than justify the increased component cost. This is the kind of feature creep we value in our design, because it multiplies potential disproportionately.

cURL-y Hue

Ars Technical has published their review of the Philips Hue, and nestled within it are a few highly relevant paragraphs:

It’s a simple matter to set a lamp’s color and brightness using HTTP. The easiest way to do it is to use the Hue app to get a lamp set exactly the way you want it, then query its status by sending an HTTP GET to http://(your hub's address)/api/(your hash) to see what the settings are. The GET request will return a JSON object showing the bulb’s on or off state, its brightness, its hue, saturation, (sort of) its CIE 1931 color coordinates, its color temperature in mireds, and a few other items. Copy the settings you want to set or change (probably “on,” “bri,” and the color settings), and you now have the basis of a cURL command to set the lamp to that state at any point.

Want to turn a lamp off? Just do cURL -X PUT -d '{"on":false}' http://(your hub's address)/api/(your hash)/lights/(light number)/state, subbing in your hub’s LAN IP address, your hash, and the number of the light you want to turn off. Want the lamp back on? Use the same command, but replace the {"on":false} with {"on":true}. Want to set a light to full brightness? Use {"bri":255} instead. Want to take a light at full brightness and slowly dim it down to half? Use {"bri":127,"transitiontime":100}, which will take the brightness down from 255 to 127 over 10 seconds (the transitiontime parameter is expressed in increments of 100 ms).

All of this means that the Philips Hue does indeed use REST – just like the Light – and, as a consequence, it should be a very straightforward procedure (and only just a tiny bit of code) to get the Light to control a household of Hue bulbs.

It also means that you should be able to use the web apps we’ve posted here (and will continue to post) and modify them slightly to work with Philips Hue bulbs.  Let us know if you do!


Demo: Photo Sampler


Here’s another web app that demonstrates how HTML5 and the Light can work in concert to do something that previously would have required a dedicated platform app.  The Photo Sampler uses the HTML5 Canvas 2D and File interfaces to allow the user to pick a photograph (or take a photograph) from the device – which could be a computer, tablet, or smartphone.  It then puts that image onto the canvas, and where the user touches the image, the color at the touch point is sent to the Light using REST.

Although it’s still a wee bit buggy on iOS (which seems to take great liberties with EXIF data), it works quite well.

Here’s a link to the source. It’s a mix of HTML5 and Javascript. Enjoy!

HTML5 Web Apps on the Light

With our growing REST API, it’s possible to code applications for the Light that are entirely browser-based, HTML5 and Javascript.  The ‘Countdown’ web app is an example of this.  The app turns the light green when the countdown starts – using the ajaxcolor REST command, then with two minutes to go the light turns yellow (using gradientcgi), and at one minute, red.  For the last thirty seconds, the light pulses red (again, using gradientcgi).

So without any code running on the Light – beyond the normal web stack and REST API functionality – it is possible to write a fully-functional app for the Light.  In HTML5 and Javascript.  In the browser.

This means many Light apps can be written as web apps.

Download the code for the countdown web app here and have a play.  It should work in any modern browser (IE10, Safari, Chrome, Firefox), and it will give you a template for writing your own web apps for the Light.

As a consequence of developing this demo, It’s become clear that we need to write a Javascript library for Light web apps.  That’s now a top priority.

Demo: display the air pollution level

After I posted the UV Index demo, a kind person pointed me to some live air pollution data helpfully supplied by the government of Hong Kong.  It was a very straightforward matter – using the awesome feedparser Python module – to extract the air pollution level for Central Hong Kong, and convert that to a color which is then displayed on the Light:



import feedparser

import sys, urllib2, string

d = feedparser.parse('')

for entry in d.entries:

	parts = string.split(entry.title, ' : ')

	if parts[0] == u'Central':

		pollution = parts[2]

colorval = 0x808080

# Map the value based on the value provided in the feed

if (pollution == u'High'):

	colorval = 0xFFFF80

if (pollution == u'Very High'):

	colorval = 0x80FF80

if (pollution == u'Low'):

	colorval = 0xFF8080

colorstr = "http://localhost/cgi-bin/ajaxcolor?color=0x%6x" % colorval

print colorstr

e = urllib2.urlopen(colorstr)