Author Archives: Bruce

Hacking Big Ass fans with SenseME to control them remotely

Leave a reply

Big Ass Solutions (I love that name) has an advanced ceiling fan called Haiku that includes an optional wifi-enabled component called SenseME, which is designed to be controlled by a smartphone app. Big Ass Solutions does not currently make an API available for SenseME, which is very unfortunate for folks who would like to incorporate their fans into third party home automation systems.

DISCLAIMER: What follows is information that I gleaned solely by analyzing the network traffic between the SenseME app and a Haiku fan.  None of this information is provided or supported by Big Ass Solutions, and it may change at any moment if Big Ass Solutions decides to do so. Use this information solely at your own risk. I make no guarantees whatsoever as to the current accuracy of this information. I also make no guarantees that by using this information you won’t irreparably damage your Haiku fan (bricking the SenseME, etc).

Fortunately, they use a relatively simple protocol for controlling the fans. To figure out exactly how the smartphone app and the fan communicate with one another I simply ran wireshark or tcpdump to trace network traffic to/from my iPhone. Fortunately Apple makes it fairly easy to capture packet traces of iPhones by creating a remote virtual interface (RVI) on a Mac.  All it requires is XCode, which you can download from the Mac App Store.  I won’t go into details of setting up an RVI since Apple provides fairly easy instructions on how to do it.

By tracing the network activity of the SenseME app I was able to quickly determine that the app and the fan communicate via UDP on port 31415, and the commands are all in a fairly simple plaintext format.  A command sent from the app to the fan is just a text string that looks like this:

<ALL;DEVICE;ID;GET>

Responses sent from the fan back to the app are in a similar format, but uses parenthesis instead:

(Living Room;LIGHT;PWR;ON)

The number & meaning of each parameter in the command or response varies depending on the command/response.

When the smartphone app starts up it broadcasts a <ALL;DEVICE;ID;GET> message on UDP port 31415 so that all the fans on the same network can receive it.  The fans, in response, send a series of responses back as a number of parenthesis-delimited strings to the IP address that issued the request.  In this way the smartphone app gets a snapshot of the entire current state of the fan.

When the SenseME app sends a command to a specific fan then the first parameter in the message is typically the MAC address of the fan.  It appears that the fan will also respond if the first parameter is the name of the fan, so the following two commands should effectively be identical, assuming “Living Room” is the name given to the fan with the MAC address 20:F8:5E:AB:31:1B:

<20:F8:5E:AB:31:1B;FAN;SPD;GET;ACTUAL>
<Living Room;FAN;SPD;GET;ACTUAL>

The fan will send some status messages via UDP broadcast so that all devices on the network that are listening on port 31415 can get updates. This way if you happen to have two or more smartphones all running the SenseME app and one of them changes the speed of the fan then all the apps are notified of the new fan speed.

Here are a few of the more basic commands that I’ve made use of in my testing/analysis of the fan.  Remember that the SenseME app sends commands enclosed in <> and the response(s) from the fan are enclosed in ().  I’ve also colored the commands in blue and the responses in red:

Set fan speed to 3:

Command from app: <Living Room;FAN;SPD;SET;3>
Responses from fan:
(Living Room;FAN;SPD;ACTUAL;3)
(Living Room;FAN;PWR;ON)
(Living Room;FAN;SPD;CURR;3)

Turn the fan off:

Command from app: <Living Room;LIGHT;PWR;OFF>
Responses from fan:
(Living Room;LIGHT;LEVEL;SCALE;0)
(Living Room;LIGHT;LEVEL;ACTUAL;0)
(Living Room;LIGHT;PWR;OFF)
(Living Room;LIGHT;LEVEL;CURR;0)
(Living Room;LIGHT;PWR;OFF)
(Living Room;LIGHT;LEVEL;CURR;0)

Turn the fans motion detector on:

Command from app: <Living Room;FAN;AUTO;ON>
Responses from fan:
(Living Room;FAN;AUTO;ON)
If the motion detector senses motion then this may be immediately followed by:
(Living Room;FAN;PWR;ON)
(Living Room;FAN;SPD;CURR;3) 
(Living Room;FAN;AUTO;ON)

As you can see from the above examples it’s not uncommon to receive multiple responses from a single command sent to the fan. In some cases it’s also possible to see the exact same response twice, like receiving “LIGHT;LEVEL;CURR;0” when the light is turned off.

I’m currently only interested in basic functionality like turning the fan on/off, adjusting the speed, and turning features like the motion sensor on/off so I haven’t delved into a lot of these responses.  There are some responses like “(Living Room;LIGHT;LEVEL;SCALE;16383)” that I haven’t bothered to try to understand, or why you might receive both a “FAN;SPEED;CURR” and “FAN;SPEED;ACTUAL” when they seem to always appear together and provide the same data.

This should provide enough of a basic primer for how to interact with Haiku Fans that have the SenseME option installed.  Good luck!

 

pdmaint

Leave a reply

We use PagerDuty where I work at Care.com to manage on-call notifications, escalations, etc. It’s a great tool to manage alerts from tools and services like Nagios, New Relic, and dozens of others. They also provide a handy dandy REST API, and it should be no surprise that somebody then wrote a Python module to encapsulate it (thanks DropBox!).  Thanks to that I wrote a handy-dandy command line tool called pdmaint for my company to schedule maintenance windows in PagerDuty. Since we’ve found it incredibly useful I was able to get the powers-that-be to let us open source it.  So you can find pdmaint over at Github if you’re interested.  There’s a full set of documentation there as well.

IMAPrunner

Leave a reply

Here’s a handy little IMAP utility people may find useful. IMAPrunner was an excuse for me to learn a little more about Python programming and to also throw together something useful at the same time.  It’s a Python script that lets you associate scripts/commands with mail messages in individual mail folders.

I now have a cron job set up that checks for any e-mails I add to a “spam” folder.  If I receive any spam I just move it to that folder.  IMAPrunner will then pass the spam e-mail onto SpamAssassin, razor, pyzor, etc. and then delete the e-mail automatically. There’s really no limit to what you can trigger in response to an e-mail with it.  And I already have a few thoughts for improvements to it…

Instant Nagios Starter

Leave a reply

I was recently contacted by Packt Publishing and asked to review their book Instant Nagios Starter, by Michael Guthrie.  I’ve actively used Nagios (and forks) for well over a decade now, and have even contributed some code development to it, so I’m intimately familiar with installing, configuring, and managing Nagios environments.

Nagios is an extremely powerful and flexible monitoring platform, and those two attributes also result in it also being a fairly complex piece of software to configure if you’ve never dealt with it before.  This book does an excellent job of walking you through the steps of installation and basic configuration of Nagios on a CentOS/RHEL system.

Nagios, as with just about any complex piece of software, relies on a number of system configuration settings, files in multiple locations, etc. to run properly.  Instant Nagios Starter does an excellent job of walking you through each and every dependency so that you can get a basic Nagios server up and running in no time at all.  If you’re new to Nagios, or need to spin up a new Nagios server and may have only ever worked with existing Nagios setups in the past, then this guide will save you a lot of time and potential aggravation in getting started.

The title of this book is extremely accurate – it will get you started with Nagios in almost no time at all.  If you’re looking for anything beyond the basics of setting up Nagios then you’ll want something a bit more in depth, and Packt Publishing has you covered there as well since they also have a number of other books on the subject.

Perhaps the only thing that would make this book more valuable would be if Packt Publishing offered a download of a VMWare CentOS instance with Nagios pre-installed (or partially installed) for those who don’t want to waste any time installing linux first.

nagios-plugins patch to check_dig

Leave a reply

I use Nagios (actually Icinga) at work and do a lot of tinkering with it.  I recently needed to modify the check_dig command to allow for verifying whether a response is authoritative or not.  This is apparently something that’s asked for a lot according to some Google searching that I’ve done, so I wrote a quick patch, and I’ve submitted it to the Nagios Plugin project on Sourceforge.  Hopefully they’ll accept it, but in the meantime I thought I’d post it here as well so others can make use of it if the have a need for it.

The patch is available two ways depending on your preference.  You can just download a patched version of nagios-plugins-1.4.15.tar.gz, build the plugins as you normally would, and be on your way.  Or you can download the official version of nagios-plugins-1.4.15.tar.gz from Sourceforge and just apply this check_dig patch.  To apply the patch:

[brucep@carbon:~/tmp] tar xvzf nagios-plugins-1.4.15.tar.gz
[brucep@carbon:~/tmp] gunzip check_dig.patch.gz
[brucep@carbon:~/tmp] patch -p0 < check_dig.patch # Note, that’s a zero, not the letter o.

Assuming the patch command doesn’t report any problems you should be all set.  Just rebuild the plugins and you’re good to go.  This adds a ‘-e’ option to the command line.  If you use -e then check_dig will verify that the flags header from dig contains the ‘aa’ flag.  If the ‘aa’ flag isn’t found then check_dig will return a CRITICAL error.

If you’d like to keep track of the status of the patch on Sourceforge you can check it here.