Red de automatización de toda la casa: ¿CAN o Ethernet?

2

Estoy a mitad de camino de la construcción de mi sistema domótico. Como ingeniero electrónico / desarrollador de software, una gran parte de esto ha sido superado desde cero y espero que empiece a publicar más en mi blog y a construir / publicar mi historia y mis trabajos una vez que estén completos.

Ahora estoy en el punto de automatización de la iluminación. Tengo aproximadamente 30 interruptores de pared que ejecutan un prototipo de placa frontal con sensor táctil y ahora necesito volver a conectarlos a mi computadora de automatización integrada Win7. También necesito conectar unos 30-40 reguladores y relés.

Por lo que puedo ver, tengo un par de opciones para protocolos tanto a nivel físico como de aplicación y realmente estoy buscando comentarios o sugerencias sobre las opciones a continuación, y si alguien tiene alguna otra sugerencia.

En este momento, todos los controladores se están ejecutando en los procesadores ARM M3 y tengo pilas Ethernet y CANopen disponibles. El sistema debe ser "maestro múltiple" e idealmente debe ser compatible con ambos eventos (por ejemplo, alguien presiona un botón) y con el proceso (consultar un sensor cada 30 segundos o hacer una pregunta a un nodo específico).

CANopen

  • Corrección de errores multimaster y automática / prevención de colisiones
  • Opciones de proceso, servicio y evento para mensajes
  • Puede ser complicado "conectar virtualmente" el dispositivo. Mucha configuración potencialmente necesaria
  • Barato de implementar en hardware, relativamente escalable. Límite de 127 dispositivos en un bus. Red en cadena.

Ethernet

  • Multicast UDP, o transmisión? No estoy seguro de cuál es más apropiado
  • Probablemente tengo que colocar mi propio protocolo de mensajería o API en la parte superior para manejar todos los tipos de eventos que requiero, no estoy seguro de las acciones dirigidas por eventos
  • Red en estrella, PERO podría ser compatible con PoE, lo que es bueno
  • Más caro en hardware
  • Mucho más ampliable en software (potencialmente un número infinito de dispositivos, etc.).

¿Alguien ha recibido algún comentario o idea sobre cuál puede ser la mejor manera de proceder? Tengo la sensación de que Ethernet puede ser el camino, pero me preocupa que haya mucha más implementación requerida en el software.

Gracias

    
pregunta SeBen

2 respuestas

2

Aunque podría usar Ethernet e implementar una pila TCP / IP en cada controlador, y seguramente use UDP para transmitir lecturas / comandos / etc de sensores. Recomendaría el uso de CAN para los siguientes factores:

  1. Más fácil de implementar / Código
  2. Muy, muy ligero. Se puede integrar con controladores más pequeños. Se puede usar un MCP2515 si la MCU no tiene CAN.
  3. Puede usar CAT5 / CAT6 y usar los cables de repuesto y llevar 24V o 36V para alimentar los nodos.
  4. El marco de mensaje pequeño se puede colocar fácilmente dentro de un marco de sub-1Ghz RF si decide extender el Bus sobre RF. Solo necesita codificar una puerta de enlace CAN a RF, tal vez utilizando los módulos RFM69 de el-cheapo.

Hay un blog que explora el uso del bus CAN para un uso similar, que podría ser útil: talk2.wisen.com.au

De todos modos, si decides ir con Ethernet, UDP sería mejor, por lo que no tendrás que preocuparte mucho con el direccionamiento de nodos.

Todo lo mejor!

    
respondido por el Talk2
-5

CAN es mucho más simple porque es un RS232 / RS485 revisado pero limitado en número y funciones. El cableado es una serie estándar y es mucho más simple que la LAN. LAN y Wifi son seguramente mucho mejores porque hay más funciones disponibles, obviamente los precios son más altos. Wifi podría tener la ventaja de no requerir otros cables que los de alimentación. Muchas interfaces baratas, como las de Velleman, están conectadas con RS485 o CAN, pero WIFI y LAN son mejores si desea desarrollar sus dispositivos controlados.

    
respondido por el krufra

Lea otras preguntas en las etiquetas