MQTT5 support.

[dustin]

trafficstars

I'm not quite sure how to make a nice way to move properties around or whether to build a better abstraction to specify the protocol than lwmqtt_protocol_t, e.g.:

homePub.begin(homeMQTTServer, 1883, homeESPClient, LWMQTT_MQTT5);

The important thing to me was to pass in enough properties to publish sensor readings with a timeout so I can keep them available while they remain relevant, but have them expire if they're not being properly updated. e.g.:

        char topic[64];
        char msg[32];

        bool retain(true);
        
        lwmqtt_property_t proplist[] = {
          {.prop = LWMQTT_PROP_MESSAGE_EXPIRY_INTERVAL, .value = {.int32 = 1800}},
        };
        lwmqtt_properties_t props = {1, (lwmqtt_property_t *)&proplist};

        snprintf(topic, sizeof(topic), "%s/counter", base);
        snprintf(msg, sizeof(msg), "%d", counter);
        if (!homePub.publish(topic, msg, strlen(msg), retain, homeQoS, props)) {
            return false;
        }

[dustin]

This seems to have fallen behind a bit. I'm still using my branch as the v5 stuff is important for my use cases. Is there anything significant to be done here?

[256dpi]

Hi @dustin, sorry about that! My plan I is still to implement MQTT5 in shiftr.io to have a service to test the implementation with. This should happen soon, but ATM I'm fully committed to another project. If you don't mind I'd like to leave things like this for now and revisit this later. People that need MQTT5 will eventually find this PR and probably have the experience to get it up and running.

[gleanlux]

I would like to ask, will there be MQTT5 support in the near future? Thank you very much for your work! Regards: Gábor

[dustin]

I'm still running my fork which works quite well (I pretty much require expiring retained messages), but there are some conflicts with later changes I've not looked into.