lxp-bridge
lxp-bridge copied to clipboard
celsworth
MQTT 5 support
Extracted out of https://github.com/celsworth/lxp-bridge/pull/154
In that PR, we add retained messages for holding registers. If lxp-bridge is offline for a long time, these might become annoying.
MQTT 5 fixes this by adding a TTL to retained messages, so they disappear if not refreshed for a period. We could probably make use of this to solve that issue.
MQTT 5 implies upgrading rumqtt https://bytebeam.io/blog/rumqtt-r19-persistence-10k-load-and-public-infra/#%F0%9F%A7%AD-mqtt-5-roadmap and ruby-mqtt, at a minimum.
Do we want to retain (ahahaha) mqtt v3 support at the same time, opportunistically upgrading to v5 if the broker supports it? Looks like mosquitto 1.x supports mqtt v5, so it might be overkill to do so.
I'm not sure of the exact status of MQTT5 in the rumqttc crate. There's ongoing PRs that appear to be adding functionality, but the Github README only lists MQTT3 as "complete" so I guess MQTT5 is at-your-own-risk for now : https://github.com/bytebeamio/rumqtt#-rumqttc
And I'm struggling to find much documentation on how to use it, other than adding in a few ::v5 namespaces into the modules we include. There's not many resulting errors to fix, to be fair - seems like topic has changed from a String to Bytes (or Vec[u8] or something), and Publish now has two args rather than one, but nothing insurmountable.
I'm wondering if I'd rather wait for it to become more stable and documented, indicating some level of confidence in using it. It will end up holding up v0.10 though if we want to get this retain TTL in.
I don't think this one is super-important for v0.10 personally, it could come after.
Fair enough, I'll bump the milestone. Reckon v0.10 is good for release then?