Compensaciones de XBee vs. Wifi para sensor remoto y cámara

Estoy planeando construir un sensor remoto para la entrada de mi casa, que está a unos 250 pies de la casa (línea del sitio). El requisito básico es notificar a mi sistema HA cuando la puerta se abre o se cierra, pero también me gustaría tomar una foto de la puerta cada vez que se abre. Tengo energía de 120 VCA en la ubicación de la puerta. Estoy pensando que una cámara Raspberry Pi+ sería ideal para esta aplicación, pero necesito elegir un método de comunicación inalámbrica.

La ubicación está en el borde de donde mi teléfono capta nuestra red WiFi, por lo que WiFi puede ser una opción, aunque el dispositivo específico elegido sería un factor. Si puedo encontrar un dispositivo WiFi con suficiente alcance, este sería el más simple, ya que simplemente puedo usar HTTP y/o FTP para notificaciones y transferencias de archivos.

XBee, especialmente con las versiones Pro de mayor potencia, parece que tendría mucho alcance (y ya tengo un Pi dedicado en mi garaje que podría ser el extremo receptor), pero tendría que inventar un protocolo para mover las actualizaciones de estado y contenido fotográfico a través de la conexión serie XBee o configurar una conexión SLIP.

¿Hay otras compensaciones que debería considerar?

Respuestas (2)

Una red WiFi está diseñada para mantener una conexión continua. Por lo tanto, todos los dispositivos que se van a comunicar deben quemar una cantidad sustancial de energía para mantener viva la conexión o deben pasar un tiempo considerable (normalmente de 10 a 30 segundos) estableciendo una conexión cada vez que quieren comunicarse.

Al usar xBee, si hay una "estación base" que se enciende continuamente, las unidades que desean comunicarse con esa estación base pueden encenderse, comunicarse, recibir una respuesta y apagarse, a menudo en menos de 100 ms. Para algunos tipos de monitoreo de sensores, la diferencia entre encender algo durante 15 segundos y 100 ms puede ser bastante grande. Sin embargo, para que eso funcione bien, es necesario tener unidades base que estén "siempre encendidas" o que las unidades remotas sepan cuándo estarán encendidas. Los módulos Digi incluyen un modo ("modo de suspensión síncrono") que, en teoría, se supone que automatiza este último, pero requiere que todos los módulos en una red siempre se enciendan durante el mismo período de tiempo, independientemente de si tienen algo que decir. Peor,

Buena información; en mi caso, tengo alimentación de CA disponible, por lo que el consumo de energía no es tan importante como la facilidad de configuración.
@TomG: Si la energía no es un problema, elegiría XBee y simplemente tendría todas las unidades encendidas todo el tiempo. En ese modo, no transmiten nada a menos que se les dé algo que decir. Utilice el modo API con escapes; El modo transparente puede permitir que los módulos se utilicen con algunos dispositivos con interfaz en serie que no saben nada sobre los módulos Digi, pero el código que recibe "HE" [pausa] "LLO" no puede saber si lo que se envió fue "HOLA", pero el la segunda parte tomó algunos reintentos, o si el remitente había tratado de enviar "HEALTHY ARMADILLO" pero la parte del medio no pudo pasar.
La desventaja que veo con XBee es que tendré que escribir más código y/o encontrar una implementación de SLIP que funcione para Pi; Por otro lado, tengo un comienzo en una red de sensores XBee...
@supercat Estaba asumiendo que incluso en modo transparente, el XBee hace algunos reintentos, etc. para asegurarse de que se reciban todos los datos.
@geometrikal: lo hace, pero no distingue entre los datos que se envían con éxito (posiblemente con reintentos) y los datos que se abandonan después de alcanzar el límite de reintentos.
@TomG: No me molestaría con SLIP. Si usa el modo API, cualquier paquete que se transmita y reciba se recibirá como una unidad; no tendrá que preocuparse por paquetes parciales, o por recibir la cabeza de una cola con la cola de otra.
@supercat: escribir y depurar un programa en modo API para copiar archivos probablemente tomaría más tiempo que configurar SLIP, y con SLIP, no solo tendré acceso a curl/ftp/scp, tendré la ventaja de poder ssh a la caja para actualizar el código desde la calidez de mi oficina.
@TomG: incluso si desea utilizar una comunicación basada en IP, creo que sería mejor implementar una capa de IP sobre el modo API que intentar utilizar SLIP en modo transparente. Los módems de acceso telefónico con corrección de errores pueden garantizar que se recibirán todos los bytes transmitidos, en orden, o que la conexión se interrumpirá y ambos lados lo sabrán. El modo API garantiza que los paquetes se recibirán en su totalidad o no se recibirán en absoluto. Ninguna garantía se aplica en modo transparente.
Terminé usando ethernet sobre powerline. Fue plug and play, y ha sido sólido como una roca.

La solución más simple a través de wifi que tengo funcionando es: una cámara web, raspberry pi, software de movimiento ( http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome ), y al completar el evento de movimiento, sincroniza el archivos de imagen a través de wifi.

La cámara web funciona sin problemas con Motion. El uso de la cámara Raspberry Pi es mejor para el cálculo de la CPU que para la interfaz USB. Pero una cámara USB en una raspberry pi funcionará bien.

Esta configuración requiere muy poca codificación, solo configurar Motion. ¡Intentaría el rango wifi primero, si funciona excelente! Si no, prueba con xbee.

Compensaciones de XBee vs. Wifi para sensor remoto y cámara
RespuestasAquíPolítica de privacidad1y, 0v