Monthly Archives: December 2013

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