En primer lugar, está haciendo algo MUY correcto que muchos diseñadores y usuarios de IoT no: Usted considera el hecho de que la operación debe ser confiable y limitada por la latencia . No todos hacen eso, y es por eso que muchos dispositivos de IoT son realmente malos.
La elección del estándar entre 802.11 b / g / n realmente no influirá mucho en su latencia. Supongo que estamos limitando latencias < 10 ms, porque todo sobre eso "solo funcionará en el 99.5% de los casos utilizando un buen hardware WiFi".
Si estás en un escenario vinculado a la latencia, ciertamente no lo harás
- usa TCP (y por lo tanto, MQTT, que se construye sobre eso)
- use un dispositivo que emule un enlace serial lento: si sus paquetes tienen 4 caracteres y tiene 9600 baudios, entonces gastará un milisegundo solo para obtener datos del µC al dispositivo WiFi
- use WiFi, ya que no hay garantía que su estación podrá enviar dentro de una ventana de tiempo finita, en absoluto (solo una posibilidad)
Si necesita confiabilidad, por otro lado, no debe
- use UDP puro (ya que no hay ninguna garantía o comentario de que los paquetes lleguen a su destino)
- use un protocolo de radio unidireccional puro (el mismo motivo)
- use un ESP8266, que le da una ventaja de precio por la falta de pruebas, diseño y certificación para una operación de alta confiabilidad (y, por lo tanto, ningún gran fabricante de productos electrónicos usará eso sin hacer esa prueba por sí mismo, en cuyo caso módulos listos para usar de fabricantes de confianza generalmente se vuelven más baratos)
En primer lugar, define cuáles son sus requisitos de latencia y cuáles son sus requisitos de fiabilidad. Usted debe tener un papel que diga
La latencia para la comunicación de {one | two} -way debe ser < {latencia máx.} en {porcentaje tolerable}% de casos. No debe haber una probabilidad de más del {porcentaje tolerable} de perder un paquete.
Luego, puedes observar los límites teóricos de los sistemas y luego ver los límites prácticos de las implementaciones de quienes se ajustan a eso.