MQTT_MAX_PACKET_SIZE in PubSubClient 2.7.0

[abqmichael]

I am using PubSubClient version 2.7 and have found a possible problem related to defining MQTT_MAX_PACKET_SIZE for PubSubClient.

Wanting to get good at using MQTT I started trying to use and understand the ESP-MQTT-FastLED code in early 2019. At that time, I was unable to get it to go for a variety of reasons. After taking a break, I decided to break the code down to determine the sources of my problems.

One issue I ran down today is that larger packets sent through MQTT were not getting passed to the code yet smaller payloads I crafted were getting passed. An open issue in the PubSubClient library appears to be that it was designed to drop packets larger than 128 bytes. (See knolleary/pubsubclient#110.) The example packet in ESP-MQTT-FastLED is about 135 bytes and thus that packet gets dropped.

Though I'm not in agreement with the rationale of the 128 byte limit choice, it is what it is. Now ESP-MQTT-FastLED does #define MQTT_MAX_PACKET_SIZE 512. However, the discussion and my tests show that setting MQTT_MAX_PACKET_SIZE 512 in the code does not have any effect because the library is pre-compiled with a max packet size of 128. The recommended work-arounds are to re-compile the library, to choose a different library, or to use smaller packets.

My question is threefold.

First, it is apparent that ESP-MQTT-FastLED works for some people. If so, which version of PubSubClient are you using? Did you need to recompile the library?

Second, is packet design -- the meaning or ontology of the parameters in the packets. On the one hand, it does seem that the ESP-MQTT-FastLED packet design may be putting too many options in one packet leaving some options used for some effects and others for other effects. One result is that the parameters seem to have different meanings depending upon the effect chosen. Yet, I've noticed that other IOT systems (like Hue) have really complex ontologies that could never fit in 128 bytes. So I'm not sure what's right. Should IOT systems like this use a collection of different exchanges (each for different classes of effects) or one big payload designed to cover all effects the device supports.

Any clarification would be helpful.