Skip to content
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

Open
RichieB2B opened this issue Feb 21, 2024 · 5 comments
Open

Connect with MQTTv5 by default #816

RichieB2B opened this issue Feb 21, 2024 · 5 comments
Labels
Status: Available No one has claimed responsibility for resolving this issue. Type: Enhancement A new feature for a minor or major release.

Comments

@RichieB2B
Copy link
Contributor

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?

@github-actions github-actions bot added the Status: Available No one has claimed responsibility for resolving this issue. label Feb 21, 2024
@PierreF
Copy link
Contributor

PierreF commented Feb 26, 2024

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).
But there is API change between MQTTv5 & MQTTv3.11:

  • At least if using callback_api_version to version1, the callback change between MQTTv3* and MQTTv5
  • I think to clean_session vs clean_start

@RichieB2B
Copy link
Contributor Author

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 CallbackAPIVersion.VERSION2 is used?

@PierreF
Copy link
Contributor

PierreF commented Feb 26, 2024

How about attempting to connect with MQTTv5 (with a fallback to MQTTv311) when CallbackAPIVersion.VERSION2 is used?

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).

@pktiuk
Copy link

pktiuk commented May 7, 2024

That would have been a very good idea for 2.0 due to possible breaking change :/

There is already 2.0. What is the status of this issue?

@pktiuk
Copy link

pktiuk commented May 20, 2024

@PierreF

@MattBrittan MattBrittan added the Type: Enhancement A new feature for a minor or major release. label Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Available No one has claimed responsibility for resolving this issue. Type: Enhancement A new feature for a minor or major release.
Projects
None yet
Development

No branches or pull requests

4 participants