¿Qué protocolo debo usar para dispositivos de automatización en un entorno doméstico?

9

Tengo un proyecto para automatizar cosas en una casa. Soy un desarrollador pero un principiante en electrónica e IoT.

¿Qué debo usar para comunicarme de forma inalámbrica? Wi-Fi, Bluetooth ... ¿Dónde debo buscar?

Necesito una solución barata, de bajo consumo y pequeña , por ejemplo, haciendo un interruptor de luz inalámbrico adicional, o intente hacer cosas como triangularización local con un circuito integrado de mis compañeros de casa (¡no hay prisioneros! La casa es grande y es para tener un "modo de antorcha": las luces te siguen para ahorrar energía)

También cultivamos alimentos (hongos), por lo que se puede optimizar los cultivos en el futuro. También quiero abrir / cerrar algunas puertas.

Debe ser modular para que una API al final pueda ser genial.

¿Es bueno ver un circuito integrado de Bluetooth en IoT centralizado por Raspberry Pi (servidor) y controlable por Wi-Fi (o directamente a través de Bluetooth)? ¿Qué me estoy perdiendo?

smart-home wireless

— Morfeo
fuente

3

Definitivamente no es wifi debido a la preocupación de la energía, aunque es posible que Bluetooth tenga poca energía, ya que hay defectos de diseño numérico en la especificación, particularmente con respecto al uso compartido, posiblemente algún esquema personalizado entre los chips de radio / MCU de 2.4 GHz diseñados para adaptarse con mayor precisión a sus necesidades. El uso de BTLE literalmente tiene sentido principalmente si necesita comunicarse con dispositivos existentes que tienen eso, especialmente teléfonos.

— Chris Stratton

1

Para comunicarme con teléfonos, ¿qué sucede si no lo hago directamente pero manejo los datos del esquema personalizado en un Raspberry PI por ejemplo y ejecuto mi servidor con un servicio web para el teléfono / aplicaciones? ¿Tiene alguna buena fuente para aprender sobre el esquema personalizado, etc.?

— Morfeo

1

Luego puede implementar algo personalizado en ambos extremos. Solo tenga en cuenta que los pi son frágiles debido a la dependencia de una tarjeta SD que no le gusta la pérdida de energía en el momento oportuno.

— Chris Stratton

2

No estoy seguro de dónde sacaste la idea de que 2,4 GHz es caro, ya que eso está equivocado. Los transceptores son tan pequeños como un dólar, en una sola cantidad. Sin embargo, 25m pueden ser menos confiables para muchos mecanismos sin licencia, al menos si hay paredes u otras fuentes de ruido. Algo como LoRa está diseñado para recorrer distancias (mucho) más largas con poca potencia, pero existen límites mucho más bajos en la velocidad y la cantidad general de datos que puede ingresar.

— Chris Stratton

2

No estoy seguro de que haya algo fuera de la plataforma, pero la idea de BT-LE respaldada por nodos conectados wifi para obtener el rango parece sensata.

— Sean Houlihane

8

Aquí tiene una buena lista de 11 protocolos de IoT que debe conocer.

Aquí hay un resumen en caso de que el enlace se rompa algún día

Estándar de Bluetooth : especificación principal de Bluetooth 4.2 Frecuencia: 2.4GHz (ISM) Rango: 50-150m (Smart / BLE) Velocidades de datos: 1Mbps (Smart / BLE)

Estándar Zigbee : ZigBee 3.0 basado en IEEE802.15.4 Frecuencia: 2.4GHz Rango: 10-100m Velocidades de datos: 250kbps

Estándar Z-Wave : Z-Wave Alliance ZAD12837 / ITU-T G.9959 Frecuencia: 900MHz (ISM) Rango: 30m Velocidades de datos: 9.6 / 40 / 100kbit / s

6 Estándar LowPAN : RFC6282 Frecuencia: (adaptado y utilizado en una variedad de otros medios de red, incluido Bluetooth Smart (2.4GHz) o ZigBee o RF de baja potencia (sub-1GHz) Rango: N / A Tasas de datos: N / A

Estándar de subproceso : subproceso, basado en IEEE802.15.4 y 6 Frecuencia LowPAN: 2.4GHz (ISM) Rango: N / A Velocidades de datos: N / A

Estándar WiFi : basado en 802.11n (uso más común en los hogares de hoy en día) Frecuencias: bandas de 2.4GHz y 5GHz Rango: aproximadamente 50m Velocidades de datos: 600 Mbps máximo, pero 150-200Mbps es más típico, dependiendo de la frecuencia del canal utilizado y el número de antenas (El último estándar 802.11-ac debería ofrecer 500Mbps a 1Gbps)

Estándar celular : GSM / GPRS / EDGE (2G), UMTS / HSPA (3G), LTE (4G) Frecuencias: 900/1800/1900 / 2100MHz Rango: 35 km máximo para GSM; Máximo de 200 km para velocidades de datos HSPA (descarga típica): 35-170kps (GPRS), 120-384kbps (EDGE), 384Kbps-2Mbps (UMTS), 600kbps-10Mbps (HSPA), 3-10Mbps (LTE)

Estándar NFC : ISO / IEC 18000-3 Frecuencia: 13.56MHz (ISM) Rango: 10cm Velocidades de datos: 100–420kbps

Estándar de Sigfox : Frecuencia de Sigfox: Rango de 900MHz: 30-50 km (entornos rurales), 3-10 km (entornos urbanos) Tasas de datos: 10-1000bps

Estándar Neul : Frecuencia Neul: 900MHz (ISM), 458MHz (Reino Unido), 470-790MHz (Espacio en blanco) Rango: 10 km Velocidades de datos: pocos bps hasta 100 kbps

Estándar LoRaWAN : Frecuencia LoRaWAN: Varios Rango: 2-5 km (entorno urbano), 15 km (entorno suburbano) Velocidades de datos: 0.3-50 kbps.

Solo considera que:

Cuanto más larga sea la distancia que desea cubrir con la señal, más consumo de energía necesitará.
Cuanto mayor sea la velocidad de datos que necesita, mayor será la frecuencia y, por lo tanto, más consumo de energía.

Entonces sugiero ir a un protocolo de baja frecuencia; ZigBee funciona bastante bien, consume muy poco y es bastante popular. El único inconveniente es que Raspberry Pi no incluye un transmisor ZigBee, es posible que necesite un adfruit adicional.

— Lijadoras de serpiente
fuente

Esta es una buena lista, sería bueno mantener esto actualizado. Algunas cosas agregaría; Bluetooth 5 (velocidad de datos y cambios de rango) y capacidades de malla, LoRa podría subir hasta 300 kbps (esos son los módulos que he visto, pero creo que hay algunos que podrían ir aún más).

— dicobraz

6

En referencia a la lista de protocolos proporcionada en la respuesta de Snake, parece que necesita un protocolo con un rango de 20-100 m, buen rendimiento de baja potencia (idealmente pasivo, pero no conozco ninguna solución), y realmente no hay mucho ancho de banda por la parte llevada. Además, necesita algunos nodos estáticos que pueden estar menos restringidos desde una perspectiva de potencia.

BT-LE es el protocolo más ampliamente adoptado. Desafortunadamente, no creo que pueda reutilizar un teléfono celular de la misma manera que usaría un nodo (a menos que confíe en interacciones puramente pasivas con el protocolo). Sin embargo, los SoC que proporcionan este protocolo, más los periféricos suficientes para habilitar un rastreador de ejercicios o auriculares son comunes (y mejoran en especificaciones).

Si observa los SoC más recientes con una radio de 2.4 GHz, encontrará que a menudo admiten más que solo Bluetooth (solo configura la pila de software correcta), por lo que vale la pena investigar si puede obtener mejores resultados con un protocolo diferente ( pero luego tiene la pena de necesitar agregar otra radio a sus nodos estáticos). Su caso de uso parece depender de tener una indicación de intensidad de señal confiable (suponiendo que no sea necesaria la precisión del tiempo de vuelo).

Una de las tareas más importantes en esta etapa del diseño es elaborar un presupuesto de energía y un perfil de carga para el dispositivo portátil. Esto tendrá un impacto en los perfiles de sueño y las frecuencias de transmisión. Probablemente quiera usar un acelerómetro para adaptar la velocidad de transmisión (ya que la radio probablemente necesitará más energía para transmitir que solo sondear para verificar el movimiento).

— Sean Houlihane
fuente

4

Un protocolo que no figura en la respuesta de Snake son los módulos de radio para 433MHz / 868MHz / 915MHz, uno de los cuales cubrirá la banda de pasatiempos / investigación en su país, y puede usarse para crear nodos de baja potencia. RFM69 y NRF24L01 +.

https://www.mysensors.org/ los ha puesto en una configuración de red con protocolo y puertas de enlace, todos de código abierto, que hablan con una variedad de controladores existentes y ofrecen muchas oportunidades para el desarrollo tanto en el sensor / nodo como en los extremos del controlador.

— Geoff
fuente

2

Me gustaría ver algunas de las soluciones de Nordic SoC que tienen protocolos integrados. Es una buena manera de tener un chip que le permita probar diferentes escenarios, Nordic tiene SoC con la mayoría de los protocolos comunes (Bluetooth, WiFi, IEEE, ANT, etc.) en un conjunto de chips.

Comenzaría con Bluetooth, es la solución IMHO más simple y versátil. Aunque no estoy seguro acerca de la triangulación local, parece una exageración para sus requisitos, tal vez busque balizas Bluetooth.

— dicobraz
fuente