Continuando con el post sobre Arduino y MQTT (https://unpocodejava.wordpress.com/2013/06/12/cliente-controlador-mqtt-en-java-para-arduino/). Nos hemos encontrado ante la necesidad de enviar mensajes de tamaño superior al predefinido en la librería PubSubClient de MQTT para Arduino (http://knolleary.net/arduino-client-for-mqtt/), donde este tamaño es de 128 bytes.
Esta limitación la podemos ver en el fichero de cabecera PubSubClient.h en la propiedad MQTT_MAX_PACKET_SIZE:
Que es la propiedad que la librería utiliza para definir el tamaño de las cadenas de caracteres que contendrán el mensaje MQTT. En teoría, modificando el tamaño de este #define, a un valor más adecuado con el tamaño de nuestros mensajes MQTT, ya tendríamos configurada la librería para nuestras necesidades:
Pero esto es solo la teoría, ya que si solo hacemos esto, cuando empezásemos a enviar mensajes MQTT de tamaño superior a 256 bytes, veremos que llegan incompletos al servidor MQTT.
El problema, tras muchas trazas y pruebas lo encontramos en la propia librería PubSubClient cuando monta la cabecera del mensaje MQTT (http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#fixed-header), donde el segundo byte es la longitud del propio mensaje MQTT:
| bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| byte 1 | Message Type | DUP flag | QoS level | RETAIN | ||||
| byte 2 | Remaining Length | |||||||
Si nos vamos al fichero PubSubClient.cpp, al lugar donde la librería construye la cabecera (función write()), podemos ver que el “Remaining Length” de la cabecera se genera mal con mensajes de tamaño superior a 256 bytes, debido a un desbordamiento por el tipo de datos, ya que para almacenar la longitud utiliza un entero sin signo de 8 bits:
Si cambiamos este tipo de datos a un entero sin signo de 16 bits, nuestros problemas de longitud de mensaje, desaparecerán J:





Deja un comentario