5
\$\begingroup\$

I'm planning to build a remote sensor for my driveway gate, which is about 250' from the house (line of site). The basic requirement is to notify my HA system when the gate opens or closes, but I would also like to take a photo of the gate each time it opens. I have 120VAC power at the gate location. I'm thinking a Raspberry Pi + camera would be ideal for this application, but I need to choose a wireless communication method.

The location is on the edge of where my phone picks up our WiFi network, so WiFi may be an option, although the specific device chosen would be a factor. If I can find a WiFi device with enough range, this would be the simplest, as I can simply use HTTP and/or FTP for notifications and file transfers.

XBee, especially with the higher powered Pro versions, seems like it would have plenty of range (and I already have a dedicated Pi in my garage that could be the receiving end), but I would have to invent a protocol to move status updates and photo content over the XBee serial connection or configure a SLIP connection.

Are there any other tradeoffs that I should consider?

\$\endgroup\$

2 Answers 2

Reset to default
4
\$\begingroup\$

A WiFi network is designed to maintain a continuous connection. Thus all devices that are going to communicate must either burn a substantial amount of energy keeping the connection alive, or must spend a considerable length of time (typically 10-30 seconds) establishing a connection every time they want to communicate.

When using xBee, if there's a "base station" that's powered on continuously, units that want to communicate with that base station can power up, communicate, receive a reply, and power back down, often in less than 100ms. For some kinds of sensor monitoring, the difference between powering something up for 15 seconds vs 100ms can be pretty huge. For that to work well, though, it's necessary to either have a base units that's "always on", or else have the remote units know when the base units are going to be on. Digi modules include a mode ("synchronous sleep mode") which is in theory supposed to automate the latter, but it requires that all modules on a network always power up for the same length of time regardless of whether they have anything to say. Worse, the logic for lost nodes trying to rejoin the network, if enabled, is so atrocious as to be almost comic: a unit which is trying to find a network which is powered on for 5 seconds every minute may spend hours turning its radio on for longer and longer periods, up to 55 seconds per minute, and yet consistently avoid having the radio on when the network is awake.

\$\endgroup\$
9
  • \$\begingroup\$ Good info; in my case I have AC power available, so power consumption isn't as important as ease of set up. \$\endgroup\$
    – TomG
    Jan 1, 2014 at 21:05
  • 1
    \$\begingroup\$ @TomG: If power isn't an issue, I'd go with XBee and simply have all the units powered up all the time. In that mode, they don't transmit anything unless given something to say. Use API mode with escapes; transparent mode may allow the modules to be used with some serially-interfaced devices that know nothing about Digi modules, but code which receives "HE" [pause] "LLO" can't know whether what was sent was "HELLO", but the second part took a few retries, or if the sender had tried to send "HEALTHY ARMADILLO" but the middle portion couldn't get through. \$\endgroup\$
    – supercat
    Jan 1, 2014 at 21:39
  • 1
    \$\begingroup\$ The downside I see with XBee is that I'll have to write more code and/or find a working SLIP implementation for the Pi; On the other hand, I have a start on an XBee sensor network... \$\endgroup\$
    – TomG
    Jan 2, 2014 at 3:05
  • \$\begingroup\$ @supercat I was under the assumption that even in transparent mode, the XBee does some retries etc to make sure all the data gets received? \$\endgroup\$
    – geometrikal
    Jan 2, 2014 at 6:41
  • \$\begingroup\$ @geometrikal: It does, but it provides no distinction between data which is successfully sent (possibly with retries) and data which is abandoned after reaching the retry limit. \$\endgroup\$
    – supercat
    Jan 3, 2014 at 0:36
0
\$\begingroup\$

The simplest solution via wifi i have working is: a web cam, raspberry pi, motion software (http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome), and on completion of motion event you rsync the image files over wifi.

The webcam works smoothly with Motion. Using the raspberry pi camera is better for CPU computation vs USB interface. But one USB cam on a raspberry pi will work fine.

This setup requires very little coding, just configuring Motion. I would attempt wifi range first, if it works excellent! If not then try xbee.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.