Category Archives: Home Automation

Long Distance Mailbox Alert using LoRa

You’ve got mail! An IoT project using solar power and long range radio

In these pandemic times of limited mobility, I become more like a dog every day: looking forward with great enthusiasm to meals, walks and car rides. One of the daily events that’s taken on new importance is walking down to the mailbox. But it’s over 100 yards away from the house, so it’s nice to know when there’s actually something in it to collect. So I devised a means of getting an alert when the mail is delivered.

There are simple mechanical devices that set a visible flag when a mailbox is opened but ours is too far from the house to see. And the distance exceeds the range of commercially available Bluetooth and WiFi solutions. There is no source of power near the mailbox. Running hundreds of feet of cable seemed like an expensive and impractical means of solving the problem.

I cobbled together the perfect solution using a repurposed solar-powered floodlight and LoRa transmitter/receiver pair. LoRa (Long Distance Radio) works great for sending short data packets great distances. Unobstructed range can exceed several miles. LoRa modules are inexpensive and consume very little power.

An ideal IoT solar-powered enclosure

I found a $30 solar floodlight on Amazon that is perfect for this and would be for many other IoT (Internet of Things) projects. The device has a weatherproof enclosure, two user-replaceable 2200 mAh batteries and charging circuit. One screw opens it up and there’s plenty of room inside to add your own circuitry inside. The only deficiency I see with this product is that it lacks an O-ring or other means of weatherproofing, although the Amazon product page claims it is IP65 splash resistant.

Interior of solar panel before any modification

The project is described below in detail below in case you want to build something similar

Project Summary

A pair of LoRa radios is used for this project, one as transmitter and the other as receiver. The transmitter spends most of its time in low power mode with the radio sleeping. In that state it draws only around 10 mA. We’re powering it from the solar panel’s two 2600 mAh batteries, enough to power the module for 500+ hours. That’s a lot of cloudy days!

Whenever the state of the connected switch changes, the transmitter sends a short string of text: “1” indicating open or “0” for closed, followed by a space then the battery voltage. For example, “1 4.07”. The receiver listens for these packets. When one is received, an LED and/or servo are activated.

The LoRa module also echos the message to its serial port for interfacing with other systems (more about that in the next post).

Keep in mind that this project could be adapted for many other open/closed, true/false monitoring scenarios, e.g., driveway gates, doors, motion alarms, etc.

Bill of Materials

  • Hikeren Solar Light or similar
  • Pair of LoRa32u4 development boards like this set
  • An ESP8266 WiFi board (optional) like the D1 Mini (see next post)
  • Magnetic reed switch like the kind commonly used for alarm systems or other suitable contact for mailbox door
  • 10K pull-down resistor (exact value isn’t too important)

Arduino code is located at: https://github.com/RatRanch/Long-Distance-Mailbox-Alert

Assemble the Transmitter

  1. If you haven’t yet set up the Arduino IDE for use with your LoRa32u4 board, follow along with this guide. The setup only needs to be performed once.
  2. Upload the mailbox_transmitter sketch to one of the LoRa32u4 boards.
  3. Open the solar panel enclosure by removing one screw
  4. If you are attaching an external antenna, drill a 6mm (1/4″) hole in a suitable location and attach the antenna. Use an O-ring or some silicone sealant to keep it watertight.
  5. Clip the wires that attach the LED floodlight–which isn’t used for this project–to the circuit board. We will be using this cable to connect to a switch instead. Attach these wires to pins 5 and 3V3 (polarity doesn’t matter) and attach 10K pull-down resistor between pin 5 and Gnd. Solder these connections.
  6. Mount the LoRa board above the existing charging board. You can use two of the existing screw holes with spacers or a piece of double-sided tape. Make sure the charging and LoRa boards aren’t touching each other (I used a piece of Kapton tape as an insulator).
  7. Attach positive and negative power leads to the corresponding battery rails.
  8. Then re-attach the enclosure cover. Make sure the power switch on the back of the case is in the On position.

    The completed transmitter assembly interior should look something like this:
Installed LoRa Board

Here’s the installed transmitter assembly:

Installed LoRa Transmitter Assembly

Assemble the Receiver

  1. Upload the mailbox_receiver sketch to one of the LoRa32u4 boards. The code repository is here.
  2. If you just need an indication of when the mailbox is opened, you can stop here. The built-in LED will alternate between on and off every time the mailbox is opened. You could optionally connect an external LED to pin 13.
  3. Or you could have a little more fun and make an enclosure for the receiver. With a working flag that goes up when mail is delivered!
  4. You can more or less follow the instructions here to print and assemble the mailbox enclosure and mount the flag servo. The mounting holes don’t quite line up with the LoRa board but I had good results mounting it with only one screw. Double sided tape would also work fine. A nice remix of the design is here if you want a post and stand.
  5. Solder three wires from the servo to the LoRa board. Power positive goes to the 5V pin and negative to the Gnd pin. The signal wire gets attached to pin 11.
  6. Short pin 5 to 3V3 (or install a momentary switch between these pins) to test the servo action and align the flag.
  7. There is just enough room in the mailbox to fit the “rubber duckie” antenna that comes with the LoRa board if you rotate it to the 90 degree position. Cover the metal portion of the antenna with heat shrink tube, tape or whatever to prevent it from shorting the circuit board. You could also use a 78mm length of wire as an antenna but the range won’t be as good.

Operation

There’s really not much to it. 🙂

When the receiver is powered on, the flag will rotate clockwise to its down position. Every time the contact switch attached to the transmitter closes, the flag will toggle position. If you’re putting mail into your mailbox for collection, you can just open and close the mailbox door an extra time to reset the receiver flag to its down position. Or cycle power to the receiver, which will also reset the flag.

In the next post, I’ll describe how I interfaced the mailbox receiver with the awesome Indigo Smart Home Software platform. It sends a text message to my cellphone when the mail arrives.

Technical note: conflict between servo and RadioHead libraries

The RadioHead library is used to operate the LoRa 32u4 RFM95 radio. Out of the box, this conflicts with servo.h, which we would normally use for projects involving servos (more details here).

One solution is to modify the RadioHead library to eliminate the conflict by using a different hardware timer, however, I wanted to make this project easy for others to implement.

You’ll note that I’ve “rolled my own” soft servo control code in the mailbox_receiver.ino sketch (moveServo() function). This technique would not work well if any degree of precision is required but we’re just concerned about moving the flag 90 or -90 degrees for this project. Unlike other examples I found on the web, this function sends multiple positioning pulses instead of just one to prevent position drift.

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.

Price:
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.

Respectfully,

Peter Monahan
President

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:

indigo.device.create(protocol=indigo.kProtocol.Plugin,
    address="F8",
    name="Device Name Here", 
    description="Description Here", 
    pluginId="com.mycompany.pluginId",
    deviceTypeId="myDeviceTypeId",
    props={"propA":"value","propB":"value"},
    folder=1234)

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.