-
Notifications
You must be signed in to change notification settings - Fork 721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connect with MQTTv5 by default #816
Comments
That would have been a very good idea for 2.0 due to possible breaking change :/ I'm not sure we could do this without another breaking change and therefor wait for version 3.0. Broker with no support of MQTTv5 don't look a big issue, we could fallback to MQTTv3.11 (as we do for MQTTv3.11 with fallback to MQTTv3).
|
The breaking change in 2.0 and the mention of MQTTv5 on the migration page is the only reason I started looking into this. I never realized that the MQTTv5 standard was released in 2019 and that my MQTT broker already supports it. Pretty odd the client needs a special configuration to use it. How about attempting to connect with MQTTv5 (with a fallback to MQTTv311) when |
This indeed seems a good idea. It still needed to check what to do with option that are slightly different between v3 and v5 (e.g. clean_session vs clean_start), but we might probably be able to connect in MQTTv5 by default at least in some cases like the default (the one the most represented in documentation & example). |
There is already 2.0. What is the status of this issue? |
Even with v2.0.0 now released, the default protocol is still MQTTv311:
https://github.com/eclipse/paho.mqtt.python/blob/ebffdc2ca0a43fd87dfd270bbb16007591139626/src/paho/mqtt/client.py#L735
Isn't it time to use MQTTv5 by default?
The text was updated successfully, but these errors were encountered: