¿su buen resto de tráfico?
Al menos con lo que detallas ahí, no creo que sea mucho como para necesitar red Gigabit.
jeje ... no quería entrar tanto tanto en detalle, pero tienes razón: banda de ancha no necesito, menor latencia y camino más directo posible si
Una conexión via USB implica una conversión de datos: muchas veces innecesaria y además ralentiza el camino que tienes que recorrer. Súmale a esto nuevamente una conversión a nivel de software (mal que mal estás comunicando con un puerto USB y no con una tarjeta de red dedicada) y nuevamente tienes oportunidad de fallos y pérdida de memoria y capacidad de cálculo en convertir paquetes de un formato a otro. Si fuera cualquier otra aplicación diría que me da lo mismo, pero en este caso, el dichoso aparato lo tendría justamente para que haga la tarea de redirigir el tráfico de la forma más óptima y rápida posible, al menos la interna. La latencia hacia internet siempre será superior a lo que el puerto USB puede calcular y será despreciable, para esta aplicación un puerto Ethernet via USB será suficiente.
Sensores, podrías colocar 30 y dudo que requieras ancho de banda para ello.
(30 mensajes por minuto, ¿por MQTT? ¿cuánto consume eso ?)
Veamos cómo funciona MQTT (Cabe la casualidad de que me conozco el protocolo de memoria ya que he estado escribiendo un cliente que implementa el 100% del protocolo en PHP:
https://github.com/unreal4u/mqtt ): el mensaje más grande que puedes enviar via el protocolo de MQTT son 64535 carácteres (más 1 byte de terminación), como MQTT se comunica en UTF-8, significa que por mensaje puedes transferir un máximo de 264KiB. (El máximo hasta el momento que puede tomar un caracter en UTF-8 son 4 bytes, en el futuro puede que lo agranden a 5).
Sin embargo, este no es el problema. En la vida real, mandas bastante menos que eso, y justamente ahí está el meollo: lo que ocurre tras bambalinas es que envías por ejemplo un mensaje de 22 bytes, y debes leer 2 bytes. Dependiendo del tipo de mensaje, tienes que leer 2 bytes más. Con eso sabrás si debes leer 0 bytes adicionales o X bytes más. Envías un mensaje de 30 bytes. Lees 4, luego pides 1 byte más. Envías un mensaje de 4 bytes. Recibes 3. Envías 5 bytes y tienes que esperar hasta recibir un nuevo mensaje o bien hasta que sea la hora de mandar un PINGREQ. Así estás todo el día, con múltiples clientes. Si fuera una sola gran cadena de bytes continuos daría lo mismo, pero para que todo te funcione decentemente con MQTT, necesitas la menor latencia posible.
Por lo demás, ahora son 30 clientes, pero mi idea a futuro es poder controlar todas las lámparas de la casa (las conté, son 27 lámparas distintas) más muchos LED's y otras cosas chicas tales como sensores y otras cosas (Estaba pensando por ejemplo en colocar un sistema de luces en la cocina para indicar qué basura se saca un día determinado, tal como lo hizo el gallo de SuperHouse).
Según caché, sí es por USB, pero es USB 3.0
El C2 según caché es menos potente, habría que ver qué ventaja tiene uno o el otro.
He ahí el meollo del asunto: el C2 es un quad-core, mientras que el XU4 es un octa core... PEEEROOO!!!! tienen una pequeña gran diferencia: el puerto ethernet en el C2 va casi directo al proce:
Más en detalle:
https://dn.odroid.com/S905/Schematic/odroid-c2_rev0.2_20171114.pdf
Esto obviamente lo hace ideal para mis propósitos
Lo mismo con el almacenamiento, a ninguno le veo una conexión directa por puerto SATA, tendría que ser por USB no más, que dependiendo de tu sistema, podría servir o no.
Edito:
En efecto, el puerto de red va por una interfaz USB 3.0 interna
Ver hoja/ventana/página de especificaciones.
También caché que está el HC2 de la misma compañía, viene con un puerto SATA, podrías echarle un vistazo también.
Puerto SATA lo podría olvidar bajo la premisa de transferir algunas cosas deseables pero no críticas fuera de la casa. Tal como te dije, me está gustando cada vez más y más el odroid C2, por donde se lo mire
De todas formas, antes de desempolvar la tarjeta de crédito voi a investigar más al respecto.
Saludos.