A bit more on the Q

I poked at the Q Station and my light bulbs a bit more today, and ended up with a couple of Bash scripts that might be fun or amusing. One of them is a very simple GUI for changing bulb colors, and the other sends Morse code messages by blinking the light on and off. (Thanks to my partner Andi for thinking of that one!)

Bulb names are configurable but I'm lazy.

Yes, it's just the Zenity color selection dialog.

These are quick and dirty scripts using Zenity, but they work (at least under a default Ubuntu install) and make playing with the bulbs a lot easier.   I haven't tested this on any other Linux distributions but as long as Zenity and netcat are available they should work.

What I hope is slightly more interesting is that I've tried to separate out some simple but useful functions for working with the Q.  I hope these will be useful to other people in playing with the hardware.  There are Bash functions for changing the color of the bulbs, turning them on and off, and building the JSON string that the Q expects via its UDP interface.  (It's painful and error-prone to do this by hand.)

The code is up on github and can be cloned with 'git clone https://github.com/mccollam/belleds.git'.  If anyone uses this or has any suggestions I'd love to hear about it!

The Q API

I wrote about the Q and my thoughts about it at a general level recently.  I've also been tinkering with making it actually do interesting things via the API that it exposes.

The API is part of a beta firmware update, and it shows.  For example, right now the command to get a list of connected light bulbs locks up the device and requires a reboot.  I'm sure that will get fixed, and fortunately I can just read the serial numbers off of the physical bulbs themselves in the meantime.  But it does mean that it's basically impossible to write a consumer application to the API right now.

The API

The API that the Q exposes is pretty simple: it listens on a UDP port for messages in JSON.  It then returns nothing, a string, or JSON data.  It's a bit warty; anything communicating with it needs to expect different formatted data depending on the action.  I'd prefer to see it always return JSON, including when it doesn't understand the request.  Unfortunately, it never returns anything if there is an error and some commands don't get a success confirmation or even acknowledgement.  So it's possible that you think something has failed when it has succeeded or vice-versa.   I really hope that changes.

It's also not as well documented yet as I'd like.  There are fields that are entirely explained right now.  For example, the API to control the lights themselves contains fields like "effect", "matchValue", and "iswitch" which are undocumented.  So far I've determined that setting effect to "9" makes the bulb do what you say, a few other values (e.g. "8") makes it turn white no matter what color is specified, and anything else seems to have no effect at all but receives an "ok cmd!" response from the Q station.

Tinkering quickly

While it's possible to write a C, Python, Perl, etc. program as a harness to play with the Q, that's more work than I wanted to go through to just poke at it.  Plus I'm lazy and want to just do things from Bash wherever I can.

Since the Q just expects JSON messages on a given UDP port, it's possible to use netcat to do this without writing anything extra.  As an example, this will simply ping the unit and determine if it is working:

$ echo '{ ping" }' | nc -u 10.1.10.182 11600 -q 1
belled,MQ1AC43700000669,172.16.0.1,1

(This is using my Q's IP address.  You'll want to replace 10.1.10.182 with your unit's IP address.)

The "-q 1" parameter to nc tells it to disconnect after nothing is sent for one second.  Once I had this in my command history, it was a bit more convenient than hitting ^C to end the connection.

I've also used this to change a bulb's color:

$ echo '{ "cmd":"light_ctrl", "r":"155", "g":"20", "b":"255", "bright":"100", "sn_list":[ { "sn":"MD1AC44200001127" } ], "iswitch":"1", "matchValue":"0", "effect":"9"}' | nc -u 10.1.10.182 11600 -q 1

ok cmd!

(Again, my Q's IP address and my light bulb's serial number won't work for you, so be sure to change those.)

netcat allows simple interaction with the Q to interactively play with the API without having to bother with writing a full script and deal with sockets yourself.

Light bulbs with computers inside: a review of the Q

Having a weekend where I'm neither traveling for work nor booked solid socially means that I have some time to play with my nifty Belleds lighting system, the Q.  There's a beta firmware update available that exposes a JSON API, so I can actually make it do things without using the (frankly awful) mobile app they provide.  This means that for the first time, my Internet-accessible light bulbs are actually usable!

... Well, they'll be more usable when the firmware and API have the bugs shaken out (a bit more about which here).  Right now there are a few issues with it that prevent any real development against it.  But I'm confident that will come.  In the meantime, I've got some thoughts about the device itself.

The Q hardware

The Q itself is pretty straightforward.  It's basically a tiny wifi router running OpenWRT.  It exposes a very simple web interface that seems designed for the iPhone browser that really basically just allows you to turn the wireless functionality on or off and to play music, which will make the connected light bulbs play a light show.  Mine came with three bulbs and the various connectors, etc. needed to plug it all up.

And all packed in squishy foam.

The Q station itself is pretty small, and has an ethernet port, a USB port (presumably for connecting media players or USB drives full of music), and a headphone port (for connecting speakers).  The unit itself is powered by a micro USB cable, which is a nice touch.

It has an open unpassworded telnet server that logs directly into the root account.  While this can be disabled and passworded, nothing in the documentation mentions it.  So, kudos for being open, but a huge slap on the wrist for being insecure by default and not even telling anyone.  (Another thing I hope will be addressed in the future.)

The box itself is unsurprisingly light and running busybox.

Root out of the box.

overlayfs so losing power won't break anything

It is, in fact, configured for Alljoyn.

Default software

As I mentioned, the default interface it exposes is almost featureless.

Interestingly, there are some files and additional web pages on the device that aren't directly exposed.  I think some of them are leftovers from earlier devices -- the firmware seems to be made by a Chinese company that has been making embedded devices with web interfaces for a while.  A few of the more interesting ones are below:

This seems to be a much more comprehensive and configurable music service page.

MAC address cloning for weirdly restrictive networks?

Firmware updates.  There are lots of non-localized Chinese files floating around in the web directory on this device.

This seems to be some sort of testing tool, but I'm not quite sure for what.

More interesting software

As I mentioned before, the Q is running OpenWRT.  This is running locally on port 80 and seems to have all of its functionality present.

This would make a decent home router.

There's also some real weirdness in a few daemons running on the box.  For example, it pings a Chinese site (baidu.com) to determine if it's connected to the network.  Unfortunately, the script that does this restarts the networking service on the router if it can't reach Baidu, meaning that if you are blocking that for any reason or are on a network without outbound connections or DNS, the box will disconnect and reconnect repeatedly.  Yet another thing that I hope to see fixed.

Repeat after me: pinging a website outside of your control is not the same thing as a connection monitor.

Summing up

The Q is definitely not quite ready for prime time, but I think it could definitely get there with a bit more time and polish.  I'm personally excited about its potential, and especially the fact that it speaks Alljoyn.  I think this is the future of connected devices, and we're seeing only the barest fraction of what is to come.  (And also I like light bulbs that make pretty colors that I can change with a remote control.)

Ooh, violet.  Also, my partner made this lamp with a forge, a hammer, and a MIG welder.