Sunday, February 22, 2015

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!

Saturday, February 7, 2015

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.

Friday, January 23, 2015

Building and running the Alljoyn 'About' sample application

I got some nifty color-changing networked light bulbs via a Kickstarter campaign recently.  Hopefully I'll have more to say about those later when I have a bit more time (as I took some unboxing shots and poked around in the router they shipped with it and found some curious things).  But in the meantime, I've been poking around at the Allseen Alliance's Alljoyn framework.

Alljoyn is a framework that allows all sorts of nifty communication and collaboration between devices.  Imagine getting a new window-mounted air conditioner and having it and your thermostat immediately start talking to each other and getting your house to the right temperature, or your lights dimming in response to you starting a movie on your television.  There are all sorts of cool things this sort of communication could allow.

But for now I'm just trying to get it built and working with my light bulbs.  Tonight I spent a little bit of time getting it built and running the simple 'About' sample application that ships with it.  I thought the notes I took might be useful if anyone else starts playing with it. And unfortunately some of the docs about running the 'About' samples are a bit wrong, so maybe this will help someone out.

And if you do play with Alljoyn, please let me know!  Double bonus points if you can point me at some tutorials that don't start with the assumption that you've read the whole codebase and every document ever produced.  I just want to make some light bulbs blink!

Set up the environment

I used the following:

  • Virtual machine (VirtualBox) with 2x x86_64 CPUs, 1GB RAM, 16 GB disk, bridged network
  • Ubuntu 14.04 Server
  • Default packageset plus OpenSSH server
  • Applied full updates (apt-get update ; apt-get upgrade) as of 23 Jan 2015 and reboot

I initially started with libvirt but after a few minutes of trying to convince it to bridge the network device, I decided to just go with VirtualBox rather than spend all night tinkering with that.

Install prerequisites

git:

sudo apt-get install git
git config --global user.email "email@server.tld"
git config --global user.name "User Name"

Repo:

(per http://source.android.com/source/downloading.html#installing-repo)

mkdir ~/bin
PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

Build tools:

(per https://allseenalliance.org/developers/develop/building/linux)
[NB: ia32-libs was not available in the package archives but didn't seem to be necessary]

sudo apt-get install build-essential libgtk2.0-dev libssl-dev xsltproc libxml2-dev scons libssl-dev #ia32-libs

Grab sources

Per https://wiki.allseenalliance.org/develop/downloading_the_source

mkdir -p src/alljoyn
cd src/alljoyn

# Uncomment other versions below if you want something other than 14.06
#repo init -u https://git.allseenalliance.org/gerrit/devtools/manifest
#repo init -u https://git.allseenalliance.org/gerrit/devtools/manifest -b refs/tags/v14.06 -m versioned.xml
repo init -u https://git.allseenalliance.org/gerrit/devtools/manifest -b RB14.06
repo sync

Build samples

export AJ_ROOT=`pwd`
cd core/alljoyn
scons BINDINGS=cpp WS=off BT=off ICE=off SERVICES="about,notification,controlpanel,config,onboarding,sample_apps"

Run 'about' sample

(per https://allseenalliance.org/developers/develop/run-sample-apps/about/linux)

cd $AJ_ROOT
export TARGET_CPU=x86_64

# NB: The following are in the docs but are wrong.  Corrections below.
#export LD_LIBRARY_PATH=$AJ_ROOT/core/alljoyn/build/linux/$TARGET_CPU/debug/dist/cpp/lib:$LD_LIBRARY_PATH
#$AJ_ROOT/core/alljoyn/build/linux/$TARGET_CPU/debug/dist/cpp/bin/samples/AboutService

export LD_LIBRARY_PATH=$AJ_ROOT/core/alljoyn/build/linux/$TARGET_CPU/debug/dist/cpp/lib:$AJ_ROOT/core/alljoyn/build/linux/$TARGET_CPU/debug/dist/about/lib:$LD_LIBRARY_PATH
$AJ_ROOT/core/alljoyn/build/linux/$TARGET_CPU/debug/dist/about/bin/AboutClient

Friday, September 19, 2014

Guaranteed minimum income?

Seeing this MetaFilter post, I wonder if we're starting to approach Gandhicon 3 ("then they fight you") on the idea of a guaranteed minimum income.

I sincerely hope so. I honestly don't know if it's a good idea or not, but it would be great to see it discussed seriously. (And seeing it brought up in The Atlantic and actually kicked around in Switzerland seems like a good step in that direction.)

Intuitively, it seems... unwise.  Wouldn't everyone just stop working, letting the world grind to a halt?  But there are indications that when it was tried in Canada, that wasn't the case, with hours worked dropping only about 1% for men and between 3-5% for women, while hospitalizations decreased and school attendance increased.

(On the gripping hand, I may have been heavily influenced by being raised Orthodox Trekkie.)

I suspect this will become more and more of an issue as jobs continue to be lost to automation.  When self-driving cars are common, will we still have truckers?  That's 3.5 million jobs in the US alone.  And then there are the taxi drivers, bus drivers, etc.  And that's just one industry.

Something to think about.

Sunday, July 20, 2014

Using Netflix in XBMC with Ubuntu 14.04

I use XBMC to run my home theater system.  It's a great piece of software that can be configured to look and act in a huge variety of ways while remaining straightforward to use and set up.  One of its great features is an add-on system with a rich set of third-party multimedia tools.

Until recently, it was pretty straightforward to have a nice experience in XBMC under Linux using a combination of XBMCFlix and Pipelight.  Pipelight provides a way to run the Silverlight video streaming libraries under Linux and XBMCFlix launches the Netflix player in a full-screen Chrome window.  Installing these add-ons meant that Netflix worked well[1] and integrated right into XBMC.

Recently, however, Google has dropped support for the Netscape Plugin API (NPAPI) which Pipelight relies on to make Silverlight work.  Since XBMCFlix launches Chrome and can't be configured to use Firefox, this means that upgrading to a recent version of Chrome breaks Netflix support in XBMC on Linux.

Fortunately it's easy to work around this and trick the Chrome launcher used by XBMC to use Firefox instead.  It's a dirty hack and isn't a great solution for a general purpose desktop (especially as it involves uninstalling Chrome, which you might want to keep) but it does the trick on my entertainment system.

Here's how to do it:

  1. Uninstall Chrome or Chromium.  (On Ubuntu or other Debian-based distribution, you can do this in the Software Center or by typing "sudo apt-get remove google-chrome" (or "sudo apt-get remove chromium-browser" in a terminal.)
  2. Launch Firefox, put it in full-screen mode by pressing F11, and exit it with Alt-F4.  This will make it default to full-screen next time it's launched.
  3. Using your favorite text editor, create a script in your home directory called "google-chrome".  (It's important to make it all lower case and include the hyphen.  It needs to be named exactly "google-chrome", nothing else.)
  4. Copy and paste the following into the text file:

    #!/bin/bash

    for i in $@; do
        if [[ $i =~ ^http ]]
        then
          urls="$urls $i"
        fi
    done

    firefox $urls
  5. Save the file.
  6. Make your script executable so it can be launched by XBMC by opening a terminal and typing "chmod a+x google-chrome".
  7. Put your script where the launcher for Chrome would normally live by typing "sudo mv google-chrome /usr/bin".
Once this is done, you can install Pipelight and XBMCFlix in XBMC as you normally would.  When XBMCFlix goes to launch Chrome, it will launch Firefox instead.

Again, this is a bit of an ugly hack, but if you have a PC that does nothing but run XBMC this will get you up and working quickly.  There are ways that a script like this could be exploited, but the odds of Netflix including one in a URL to target Linux users of XBMC are pretty low, and if you have a single-purpose home theater system there's probably not much damage that could be done anyway.

Now go enjoy some movies!


1: Well, after you lie to Netflix about what operating system you're running. It's 2014 and they are still doing browser user-agent sniffing as if it were useful or effective.

Sunday, March 30, 2014

Adding hardware support to MAAS

MAAS and power

MAAS, or Metal as a Service, is a tool for treating physical servers similarly to cloud resources.  It lets you take a pile of hardware and assign workloads to it without worrying about all the support infrastructure underneath.  In effect, you can plug a bunch of systems into a network and have a Hadoop or OpenStack cluster up, running, and properly configured inside of half an hour.  It's really cool stuff.

But MAAS is targeted at enterprise-level hardware.  It expects things like IPMI to be available to control the hardware at a basic level.  (If your tool is going to be installing an operating system onto a computer, it needs to be able to control that computer at a level below the OS.)  I have a stack of older desktops sitting around gathering dust that I wanted to use as a cluster for experimenting at home.  They still function quite well, but being desktops they don't have enterprise features like IPMI.

Fortunately most desktop BIOSes have a setting to control what they do after a power outage.  Crucially, they can be set to turn the system on when electrical power is restored, regardless of whether the system was on or off when power was lost.  This means I could use an externally controlled power switch in place of IPMI to allow MAAS to power my desktops on and off.

Power on after power failure.  (Helpfully hidden under a random submenu in the BIOS rather than under the 'POWER SETTINGS' heading.)


I used the Web Power Switch 7 from Digital Loggers for this project.  (Warning: almost every page on their site has autoplaying audio and/or video.  Ugh.)  I'll be completely honest here -- price was the reason I chose this switch.  It allows control of up to 8 outlets and cost me just under $140 from Amazon.

My shiny new power switch.  (What do you mean, your datacenter doesn't have an oriental rug?)

Power templates


There are a few bits of MAAS that I had to touch to fully enable support for my DLI switch.  The first and most obvious was creating a power control template to tell MAAS how to talk to the switch.

When MAAS is installed, the templates that tell it how to talk to power management systems are put in /etc/maas/templates/power.  These are shell scripts with a bit of Python evaluation and substitution (surrounded by {{double braces}})that MAAS uses at runtime to build a command to control a specific system.  There are several examples to use there already, and these can be modified to suit your environment.  For example, the SeaMicro SM15000 hardware template looks like this:

# -*- mode: shell-script -*-
#
# Control a system via ipmipower, sending the seamicro specific hex codes
#
{{py: power_mode = 1 if power_change == 'on' else 6 }}

{{ipmitool}} -I lanplus \
    -H {{power_address}} -U {{power_user}} \
    -P {{power_pass}} raw 0x2E 1 0x00 0x7d 0xab \
    {{power_mode}} 0 {{system_id}}

I started by simply replacing one of these templates with my own code.  Because the DLI Web Power Switch can be controlled via HTTP, I just needed to build a GET request for the outlet I wanted to control and send it to the switch, like this:

#!/bin/sh
# -*- mode: shell-script -*-
#
# Control a system via the Digital Loggers, Inc. RESTful interface
#
{{py: power_mode = 'ON' if power_change == 'on' else 'OFF' }}

wget --auth-no-challenge -O /dev/null \
    http://{{power_user}}:{{power_pass}}@{{power_address}}/outlet?{{system_id}}={{power_mode}}

Once I had this template replacing the original sm15k template, I was able to control my switch by telling MAAS I had SeaMicro hardware.  Success!

Better integration


I could have stopped there with a working system.  But it bothered me a bit to lie to MAAS about my hardware.  And what if someday I or someone else wanted to mix the DLI switch with actual SeaMicro hardware?  Replacing the sm15k template with my DLI template wouldn't work then.

It turns out that there are two places in the MAAS code that need to be modified to make it aware of a new power switch.  In the MAAS source, these are src/maasserver/power_parameters.py and src/provisioningserver/enum.py.  power_parameters.py is where the real definition of a new power switch is; enum.py just needs an entry in two lists to make the UI show the switch as an option.  (There's a comment in enum.py to the effect that adding the switch name in it will not be necessary at some point in the future, but at least as of March 2014 it still is.)

The code needed to add a power switch is straightforward.  Provide the variables the switch will need to operate a system (e.g. outlet number, IP address of the switch, credentials, etc.) and give them names that can be referenced in the power template later.

Success!


The code I added can be seen in Launchpad (click "expand all" to see the diffs).

Once I added the code there, I was able to rebuild MAAS and see my new switch as an option.  It all works, and now my old desktops have new life!