I’ve been wondering about the upcoming changelog for v4.7.0. It mentions the use of shared subscription, but this is not a feature of MQTT 3.1.1. I cannot seem to connect a new build of Chirpstack to RabbitMQ 3.12.x, while it seemed to have no problems connecting to Mosquitto.
RabbitMQ does not support MQTT v5 yet, and this is a difference between it and Mosquitto. According to the code in mqtt.rs, AsyncClient comes from the v5 module.
Since there seems to be no setting to avoid the use of MQTT v5, does this imply that MQTT v5 will become a requirement? Will there be an option to support v3 MQTT brokers?
I’ve long been (years) using shared subscriptions successfully with ChirpStack and MQTT, simply by setting my topics accordingly. I haven’t checked the commit log to see what you’re referencing, but it seems like that could (should) be a configuration left to the user.
@bconway witch MQTT Broker do you use? I tried today to setup 3 ChirpStack instances connected to a vernemq broker using shared subscription. Works not to bad but I have often (maybe 30%) trouble with forward the answer from ChirpStack for a confirmed message back to my endnode… I only passed this in the region.toml:
To clarify, I am referring to the internal link between the Chirpstack LNS and the Gateway Bridge (GWB), not the link between Chirpstack and your application (which is the MQTT integration).
I realize that Brocaar implemented shared subscription in 5108f44.
But the change to use MQTT v5 took place with the switch to rumqttc.
I modified this file and the other one for integration, in order to let it to continue working with MQTT v3, so I now know for sure that it was a code change that brought about this incompatibility.
As for the changelog message, I was referring to the text for the upcoming v4.7.0 release on the changelog web page.
@jka : even without shared subscription, there should be no problem because only one Gateway Bridge instance should have an active connection with your LoRa gateway; this component will subscribe to the downlink command topic, if and only if it has an active session with the gateway.
You seemed to have modified the event topic. This would be for uplink messages from the gateway bridge, but does not affect the downlink messages to the gateway bridge.
So I think you may need to do troubleshooting, to determine why your downlink acknowledgement cannot go back to the node. Perhaps check the logs, to see whether the gateway bridge got the downlink request from Chirpstack and whether your gateway received the downlink request successfully?
@jka I’ve successfully used shared subscriptions with Mosquitto and VerneMQ, both for ChirpStack and other uses of MQTT. However, I prefer to stay away from Verne because I’ve had it too frequently end up in a split brain situation when clustered, even in the absence of shared subscriptions.
I’ve also heard good things about HiveMQ, but never used it.
@sp193 I think you meant to address @jka, but I agree with your analysis.
Now that I look at the changelog, I’m happy to see shared subscriptions are configurable. I have been setting them up simply using event_topic. That being said, I don’t think it’s a great default, for reasons already discussed.
I once evaluated HiveMQ’s performance against RabbitMQ and it was amazing in terms of performance. But it costs a lot in licensing fees. In the end, I’ve been staying with RabbitMQ. Which is also Erlang-based, like VerneMQ.
On the contrary, the code change to Chirpstack did not make the use of shared subscriptions or MQTTv5 configurable. But rather, it looked like the direction is towards the use of MQTTv5, with a shared subscription between the LNS and Gateway Bridge component. Clearly, there are benefits for adopting MQTTv5 and also using a shared subscription there, but there is no way to opt out of the use of MQTTv5 (which is not backward-compatible).
Today, I attempted to modify the two mqtt.rs files to support both the MQTT v3 and v5 options. But my inexperience in Rust is making it nearly impossible to complete well. Even if I do, the patch may just be low quality work.
But, I’ve also been thinking whether this is necessarily a dealbreaker for me. RabbitMQ 3.13 is supposed to come with MQTTv5 support, which is also supposed to be released very soon.
Some MQTT brokers already implemented the shared-subscription feature, using the MQTT 3.1.1 protocol. Since MQTT5, this feature is now standardized.
Previously, I was using the Paho MQTT client, but the v4.7 release replaces this client with rumqttc (crates.io: Rust Package Registry). As rumqttc does not provide a generic client for both MQTT versions, you pick either one or the other:
As most uses are using Mosquitto, and (most / all) other MQTT brokers do support MQTT v5 as well, using the v5 client seemed logical to me given the shared-subscription feature which is part of MQTT v5. MQTT v5 support was added to Mosquitto v1.6 (released in 2019).
I read that the plan was to release this end of 2023. While the latest stable is still v3.12, there are v3.13 release candidates, so I expect a stable release should follow shortly.
Hi Brocaar. Thank you for taking the time to read through this thread and to reply.
I cannot use a release-candidate, but it is true that this wouldn’t be a problem sooner or later. When I originally started this thread, I was indeed more concerned that perhaps necessary. Having used RabbitMQ for a long time, I wondered whether this was a breaking change with wide-reaching effects. MQTT v5 probably just isn’t as new and as uncommon as I remembered.
Indeed, I tried to get Chirpstack to support both clients, but I could not find a elegant way to do it.
I believe that simple is best, so your current approach of only using MQTT v5 is probably the best.
So after all that, the only thing I have left to say, is that it would be good if the final release notes for 4.7.0 could mention that Chirpstack now requires MQTT v5.
