Category Archives: Home Automation

Controlling devices with Indigo and Amazon Echo (Alexa)

A recently added plugin for the superb  Indigo Smart Home Software platform enables voice control of devices like lights, thermostats, fans, shades and garage doors–to name just a few–via an Amazon Echo DotEcho or Fire TV.  It works seamlessly with the Lutron RadioRA 2 plugin that I developed and is also presumed compatible with the Lutron Caseta Smart Bridge Pro (although this has not been formally tested yet).

The plugin works by emulating a Philips Hue bridge.  Setup is easy.  Just install the plugin and select the Plugins->Alexa-Hue Bridge->Manage Devices… menu item.  Choose the devices you wish to control (up to 27) and then tell Alexa to discover your devices either by saying that or by using the Alexa app.

The 27 device limit is set by Amazon’s Alexa implementation, however, if you reach that limit, you can set up a Device Group in the Virtual Devices interface to group devices are typically controlled together into a single device.

Alexa currently recognizes only “turn on”, “turn off”, and “dim” commands, however, it’s possible to control devices that don’t natively support on/off/dim by creating virtual devices.  For example, I created a virtual device called “heat” that controls a RA 2 thermostat.  When I get a chill and say “Alexa, turn heat on”, it invokes an Indigo Action group that sets the nearest thermostat to 74 degrees.  “Alexa, turn heat off” sets the thermostat back to 68 degrees.

If you’re already running Indigo, I highly recommend adding a modestly priced Echo Dot to seamlessly add voice control to your automation setup.

Switching between HDMI and analog audio on a Mac

Here’s a proven fix if you need both analog and HDMI audio outputs and require a way of switching between them.  In my case, I had an application where a rack mounted Mac Mini serves as both a media server and an audio source for a whole house paging system.

I first tried using the headphone output as an analog audio output.  The problem is that if anything is plugged into the headphone jack, it is not possible to select HDMI for sound output via the Sound preference panel or via any other means.  Various people have posted methods for outputting audio to both HDMI and headphone out simultaneously, but my application requires only one output to be active at any given time.

The hardware piece of the solution is a relatively cheap Turtle Beach USB DAC.  I’d imagine other USB audio converters would work equally well.

After plugging in the DAC, I confirmed that I could switch audio sources from the Sound preference panel.

The next step was to to automate the audio switching.  I found various Applescript techniques on the web for doing this by scripting the sound preference panel UI, but that approach seemed kludgy and probably slower than using a compiled command line tool.  If such a tool is included in OS X Mavericks, I couldn’t find it.  Fortunately, a generous developer created an output switching utility called audiodevice, which is available here.

Audiodevice works perfectly but has one minor quirk.  Some output devices have trailing spaces after their names, which need to be included in audiodevice commands.

Here is an example of a shell script that uses audiodevice to switch audio output from HDMI to USB DAC, plays a sound effect, outputs a string that was passed to it from the command line as text to speech, and then switches back to HDMI:

/usr/local/bin/Audiodevice/audiodevice output "USB Sound Device        "
/usr/bin/afplay "/Library/Audio/Apple Loops/Apple/iLife Sound Effects/Machines/Communication Engaged.caf"
say $1
/usr/local/bin/Audiodevice/audiodevice output "HDMI Matrix  "

Notice the spaces after USB Sound Device and HDMI Matrix.  If you are not using the Turtle Beach DAC, the USB DAC may have a different name.  Use the audiodevice output list command to get a list of the audio output devices installed on your Mac.

Vehicle detection using iAutomate RFID

One item on my to-do list for a long time was to enable our home automation system to detect the comings and goings of our vehicles.  Each has an EZ-Pass badge, so I figured slam-dunk, just find an appropriate active RFID reader and we’re done.  But I was unable to find a cost-effective solution.  (But wouldn’t that be an awesome Kickstarter project . . .)

I also explored homebrew solutions using Bluetooth modules and Wi-Fi but laziness triumphed when I heard about a plug and play long range RFID kit for Indigo.  (There are also versions available for Homeseer and Crestron.)  The kit comes with a reader module and two RFID tags.

Overall, I give this product a B+.  It works well but you have to get past a few annoyances.  #1, the price.  I think iAutomate is making a mistake with the pricing.  $549 for the “starter kit” puts this product out of reach for a lot of people.  I’m taking a very rough guess that the whole kit costs well under $100 to produce.  iAutomate should really consider a $399 price point (or <shudder> $199?)

Next annoyance:  WTF with the pinout?  The readers have RJ-45 (ethernet style) jacks to carry 12-volt power and RS-232 serial signal.  But, as the manual cautions, if you plug this thing into Ethernet, something will surely fry.  iAutomate provides a lovely color engineering diagram showing how to terminate an eight conductor RJ-45 plug into the custom, 4-conductor pinout that the reader uses.  Ignoring that will make many, many crispy devices on your LAN. Gosh, if you’re gonna insist on using a proprietary pinout, at least use a proprietary connector.  Or an RJ-11 that won’t get confused with Ethernet?  Or better yet, just put an adaptor in the box to convert to standard Ethernet pinout.

And yet another nit.  The reader case doesn’t have any sort of mounting flange.   I just used a couple of cable ties with screw holes to fasten the reader to a wall.

iAutomate says you need to use a USB-to-serial converter that uses the FTDI chipset.  And they mean it.

Initially I tried connecting both the RFID reader and a Lutron RadioRA 2 main repeater to a Keyspan 4-port adapter (which does not use the FTDI driver). This combination was catastrophic!  The computer crashed every time the RFID reader saw a tag.  So I tried leaving the Lutron repeater on the 4-port adaptor and putting the RFID reader on a single port Keyspan unit that I had in my parts box.  This had the frustrating result of working perfectly except when a tag would first come within range of the reader, causing the Indigo plugin to reset communications.

Finally, I plunked down 12 bucks for a generic FTDI converter and voila, the reader worked reliably!  I still don’t understand why the Keyspan adaptor, which is my go-to device whenever I need to do USB to serial conversion, didn’t work.  iAutomate’s Indigo plugin is written in Python, using the same libraries that I used for the RadioRA 2 plugin, so it would be reasonable to assume that both devices would be hardware compatible with the Keyspan.

The manual also cautions that placement of the RFID reader and orientation of the tags may require some trial and error.  This couldn’t be more true.  I had to try about a half dozen locations for the reader before finding one where all the tags could be reliably read.

Conclusion:  an effective, but expensive and tricky to install device.

Update (May 21, 2014):  I am revising my overall assessment of this product to an A- for the following reasons:

  1. The latest version (2.1) of the iOS RFID Track app adds signal strength display and an improved UI, among other things.  It’s a real pleasure to use and is available from the iTunes Store.
  2. I recently needed technical support for the Indigo plugin and was very satisfied with the experience.
  3. Peter Monahan, the President of iAutomate, explained the reasoning behind several of the product’s pricing, manufacturing and design decisions to me.  For example, their decision to use RJ-45 connectors now makes sense to me.  Here are Peter’s remarks:

I thought I would take a moment to address some of the concerns that you had and then mentioned in your remarks. I hope to provide you with a better understanding.

The hardware devices cost us far more to manufacture than you cited.  Far more.  Many users are not aware that all of the RFID devices have FCC, IC and CE approvals; this adds tremendous cost to the hardware. We don’t have a choice in the USA, the devices must be FCC listed. We also sell in Canada and Europe.

We fight the temptation to have the devices manufactured in Asia.  There are non-financial costs associated with “making it cheap in China” and we are not willing to compromise.

As you are already aware, we provide free technical support for the product M-F 8am-5pm and are often available outside of those hours and on weekends.

The plugins (yes there are two) cost thousands of dollars to develop and are the most professional, full-featured, reliable,  detailed and documented plugin available for Indigo, bar none, yet they are bundled for free with the hardware.  The hardware was extensively tested by a team of Beta Testers prior to release (not on a single workbench). The cost of this development and continuing updates is priced into the hardware.

Similarly, RFID Track for iOS cost thousands of dollars to develop and is available for Free via iTunes for unlimited devices.The cost of this development and continuing updates is also priced into the hardware.

There is a lower cost “LE” version of the kit available for those who do not expect to expand their network beyond a single reader that sells for $399.00, but the higher cost kit sells better at $549.00.

FTDI Chipset:
FTDI provides the most current driver support and updates for OS X. During development, it was discovered that the Prolific brand chipset was often “bootlegged” and despite the amount of Prolific devices on the market, Prolific would not support many of them because they were not authentic Prolific chipsets.  We were not willing to put our reputation on the line if performance suffered because of a bad or “knockoff” adaptor.  I made the executive decision to standardize on FTDI.

The problem with “non-FTDI” adaptors is amplified, because our data stream is real time data ALL THE TIME. Even when no tags are detected, the reader sends an “empty packet” every 40ms to make certain the buffer is empty and the tag data is real-time. This empty packet also acts as a heartbeat. Other chipsets could not handle the data stream; we deemed them to be cheap, weak and inefficient. Sometimes, they were cheap knockoff copies of other chipsets.

The RJ45 Connector:
Depending upon how you terminate the reader, it has the ability to communicate via RS232 or RS485 via the RJ45 connector, so six terminations are possible out of 8 (see the drawing that was provided with kit). The RJ45 connector is the least expensive connector for providing 6, but up to 8 connections.  If we used a proprietary connector, the price would increase and Customers would be very unhappy that we “force” them to use our proprietary connectors.

The single biggest reason that standard Ethernet cables cannot be used is because such a configuration would connect RS232 AND RS485 at the same time and the reader would not detect the correct protocol for reliable communication.

The warning labels are because We’ve had Customers skip over reading the wiring diagrams as well as the manual and connect the reader directly to an Ethernet port or switch out of ignorance.  Other manufacturers place warning labels on clothes irons, cautioning the user not to iron their clothes *while on their body*.  I guess this is our version of that warning label, but if you ignore our warning, I assure you that you will not burn your flesh.

Thank you again for your business, we appreciate you.


Peter Monahan

Importing RadioRA 2 devices into Indigo

In a recent post, I wrote about a plugin I made for Indigo to add support for Lutron RadioRA 2 devices.  I can’t say enough good things about this software.  It’s rock solid reliable and extremely flexible.  Among other things, I have Indigo set up to email a picture to me when somebody comes up the driveway (but only when nobody is home; how cool is that!) and detect house occupants’ presence by looking for their cellphones on the wifi network.

So it got to be time to add the 80+ RadioRA 2 devices in the house to Indigo’s database.  Although this would be a one-time task, I really dreaded the drudgery of typing in all those device names and properties.  So I fetched the device database from the RadioRA 2 main repeater (at http://[Repeater IP Address]/DbXmlInfo.xml).  This produces an XML file with complete information about the RadioRA 2 installation.

Indigo allows devices to be added to its database programatically.  The Python syntax looks like this:

    name="Device Name Here", 
    description="Description Here", 

So far so good.  My original plan was to use Python to parse the XML file and create the devices.  So I cracked open Mark Lutz’s excellent reference book Learning Python.  Despite Lutz’s clear examples, I just couldn’t get the XML file to parse.  (It turned out to be an issue with the XML file itself).

Not wanting to invest too much time writing a program I’d only use once, I came up with a different approach.  If I could extract the XML data into an Excel friendly format, I knew I’d be able to cobble together the Python code I needed for Indigo.  I found this awesome online XML to Excel conversion tool but it threw an error when I tried to upload the XML file.

I opened the file with BBEdit and used the Tidy, Reflow Document from the Markup menu to make the unformatted XML more readable (you just gotta love BBEdit).  Something didn’t look right.  The node “Areas” was defined twice.  WTF?  So I trimmed everything from the top of the file to just before the second “<Areas>” tag.  Then I jumped to the bottom of the file and trimmed everything after the first “</Areas>” tag.  Voila!  The file was processed by the online conversion tool and it returned a nicely formatted Excel workbook.

After a bit of further manipulation in Excel (and one string concatenation function that will make your head swim), I had all the Python code generated.

If you’d like to use this technique, take a look at the Excel Spreadsheet that I posted here.  It should be self-explanatory but give me a shout if you get stuck.  Copy the results from column H of the first tab and paste into Indigo’s scripting shell.  You should name all of your areas/rooms in Indigo’s devices tab prior to importing your devices.

An Indigo plugin for Lutron RadioRA 2 and Caseta

Lutron got a lot of things right with its RadioRA 2 lighting control system.  There are over 25 device types, including dimmers, thermostats, shades, keypads, and handheld controls.  The switches work equally well in new construction and retrofit applications.  Wireless communication is robust and the device build quality is flawless.

The only downside is that setting up and maintaining anything beyond a rudimentary installation will require programming via the RadioRA 2 Essentials configuration software, which is only available to Lutron trained and approved technicians.  While I can understand Lutron’s desire to maintain it’s brand image by requiring professional installation of its products, I think they are doing a disservice to consumers by not giving them the ability to change common settings like dimmer on  levels and device scenes.  The obvious solution would be to release a “hobbled” version of the Essentials software that would expose only those settings that couldn’t get users into too much trouble.

Edit (3/2016):  Lutron addressed this with the introduction of Caseta, a consumer friendly solution that supports up to 50 devices.

The Lutron integration protocol, however, is a completely open and documented means of monitoring and controlling a Lutron system.  Communication with RadioRA 2 devices is done via the main repeater.  Commands are sent/received as plain text.  For example, the command “#OUTPUT,41,1,100” tells the repeater to set the level of dimmer #41 to 100%.  Both serial and IP connections to the repeater are available.

The main repeater includes some basic timer and “virtual button” functionality but doesn’t support advanced features like conditional events or messaging.  I think Lutron made the right decision by leaving this stuff for third party products to support through its integration protocol.

My initial plan was to build a set of OS X tools for RadioRA 2.  It’s easy enough to script actions using built-in command line tools like netcat (nc).  But then I stumbled upon a home automation product called Indigo, which provides every control and monitoring feature I could imagine and more.  Out of the box, Indigo does not support RadioRA 2 devices (Z-Wave, Insteon and X10 interfaces are natively supported).  However, additional types of hardware can be supported via 3rd party plugins.

The Indigo documentation is very good and lots of plugin examples are available so it was relatively easy to write a RadioRA 2 plugin even though I had very limited experience with the Python programming language.  The latest version of the plugin can be downloaded here.

This initial release is by no means complete but supports the most common RadioRA 2 device types.  With the exception of phantom buttons and LEDs, you should also be able to control devices on a HomeWorks QS system but I haven’t had the opportunity to test that.


  1. Download the plugin zip file and double-click it to expand. Double-click the Lutron RadioRA 2 plugin to install it.
  2. You need to connect your Mac to the main repeater’s serial port using a USB to serial adapter.  Although it costs more than most generic adaptors, I highly recommend the Keyspan adapter, which is solidly built and universally supported.  I also feel more comfortable hooking up a quality adapter to a repeater costing $400+!  You will also need a 9-pin serial cable (and possibly a serial to ethernet extender kit if your computer is more than 25 feet from the repeater).
    Edit (3/2016):  Beginning with version 2.0.0, the plugin also supports Caseta Smartbridge PRO controllers.  You can connect your Indigo server to a RadioRA 2 repeater by either serial (still preferred) or IP Ethernet. Caseta Smart Bridge PRO only supports ethernet connection. The initial configuration dialog will prompt you to specify a serial port or IP connection. If you check the option for IP, you must enter a valid username and password. For Caseta systems, this is the telnet login, not the login you use for the Caseta app.


  1. Every RadioRA 2 device has a unique Integration ID, which you will need to identify it to Indigo.  You can get a text or XML file containing all the device IDs by running an integration report from the RadioRA 2 Essentials software or by downloading an XML file from the main repeater at this url: http://[Repeater IP Address]/DbXmlInfo.xml
  2. Dimmers, Switches,  Fans and Thermostats can be added by clicking the New button on the Indigo Device panel and specifying the device’s integration ID.
  3. A unique Indigo device type for shades is not defined in the initial plugin release, however shades can be assigned to dimmer devices.  100% represents fully open and 0% is fully closed.
  4. In the current plugin implementation phantom buttons and phantom LEDs get assigned to the same Indigo device.  Button IDs are in the range of 1-100 and LED IDs are 101-200.  Each phantom button has a corresponding led.  For example, LED 101 is assigned to button 1.  To add a button/LED pair to Indigo, specify the integration ID of the LED.
  5. Operating and monitoring status of the Lutron devices from Indigo should be self-explanatory.

Limitations in plugin version 2.0.0

  1. Main repeater phantom buttons can be set up in multiple ways but the plugin currently only supports On/Off commands.  So, for example, if a phantom button is defined as a toggle, clicking its On button in Indigo will turn the device on and clicking On again will turn it off.  Indigo’s Off button will have no effect on a phantom button that’s defined as a toggle.
  2. The Lutron fan switches have four fan speeds (low, medium, medium-high, and high) but only three of these speeds are selectable from the Indigo GUI.

When time permits, I’d like to add support for Pico handheld remotes, which are very convenient for controlling groups of shades.  Also the fact that the RA2 repeater makes its entire device list (among other things) available as an XML file opens up the possibility of importing the RA2 devices into Indigo instead of manually adding them.