Primeiro de tudo, você está fazendo algo MUITO certo que muitos designers e usuários da IoT não fazem: Você considera o fato de que a operação precisa ser confiável e limitada pela latência. Nem todo mundo faz isso, e é por isso que muitos dispositivos de IoT são realmente ruins.
A escolha do padrão entre 802.11 b / g / n não influenciará muito sua latência. Suponho que estamos limitando latências <10ms, porque tudo "funcionará em 99,5% dos casos, usando um bom hardware WiFi".
Se você estiver em um cenário de latência, certamente não
- use TCP (e, portanto, MQTT, que é construído sobre isso)
- use um dispositivo que emule um link serial lento - se seus pacotes tiverem 4 caracteres e 9600 bauds, você gastará um milissegundo apenas para obter dados do µC para o dispositivo WiFi
- use Wi-Fi, já que não há garantia de que sua estação poderá enviar dentro de uma janela de tempo finito, de todo (apenas uma probabilidade)
Se você precisa de confiabilidade, por outro lado, não deve
- use UDP puro (já que não há garantia ou feedback de que os pacotes chegam ao seu destino)
- use um protocolo de rádio unidirecional puro (mesma razão)
- use um ESP8266, que tira vantagem de preço por falta de teste, projeto e certificação para operação de alta confiabilidade (e, portanto, nenhum grande fabricante de eletrônicos o utilizará sem fazer esse teste sozinho, caso em que módulos prontos de fabricantes confiáveis geralmente ficam mais baratos)
Portanto, antes de tudo, defina quais são seus requisitos de latência e de confiabilidade. Você deve ter um pedaço de papel que diz
A latência para a comunicação de {one | two} vias deve ser <{max latency} em {porcentagem tolerável}% dos casos. Não deve haver uma probabilidade superior a {porcentagem tolerável}% de perda de um pacote.
Então, você pode examinar os limites teóricos dos sistemas e, em seguida, os limites práticos das implementações daqueles que se encaixam nisso.