search

homieiot / convention

🏡 The Homie Convention: a lightweight MQTT convention for the IoT
https://homieiot.github.io/
Other
717 stars 61 forks source link

MQTT Version 5 Support #98

Open ThomDietrich opened 6 years ago

ThomDietrich commented 6 years ago

This is a long-term discussion into the support/consideration of MQTTv5 in the Homie convention.

Generals statement so no one get's a wrong idea:
MQTTv5 support by Homie is currently not supported nor considered!

As I've seen more and more side-chatter regarding MQTTv5 specifics in issues recently, I thought it would be a good idea to create a place for the topic. Feel free to add your ideas regarding Homie over MQTTv5.

http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html https://blog.codecentric.de/en/2017/11/hello-mqtt-version-5-0/

davidgraeff commented 6 years ago

Mqttv5 new features are important for broker and client implementations, but is it that game changing for a topic convention? Do you have any particular feature in mind? I may have overlooked something.

euphi commented 6 years ago

After a quick look on what's new, I only see that content-types may be interesting, e.g. for the "$location" discussion. Everything else seem implementation-specific to me.

What's not clear to me, if it is necessary (or at least useful) to provide a "MQTT version" device attribute? This may be useful, if it was possible for MQTT clients of different versions to communicate over the same broker or via proxy?

jamesmyatt commented 6 years ago

My suspicion is that MQTT 5 support will be slow, so it's best to focus on the current versions.

davidgraeff commented 6 years ago

@jamesmyatt Don't underestimate hypes. All big brokers have mqttv5 test releases already (except Moquette :/) and paho developers are working on mqttv5 only at the moment (fully neglecting the mqttv3 client) on the client side for java,c and python. I guess Mqttv5 will be there as fast as Mqttv3.1 got established after the spec release.

If anybody will write an embedded mqttv5 client is another story of course.

Mqttv5 doesn't help the convention much anyway. Custom properties per topic is a funny thing. That's the analogy to attributes in homie.

jamesmyatt commented 6 years ago

@davidgraeff , I follow the Python Paho client closely, and I haven't seen any indication that they're working on MQTT v5 at all: e.g. https://github.com/eclipse/paho.mqtt.python/issues/213

The C client however is quite active on this: http://modelbasedtesting.co.uk/2018/04/30/the-new-mqtt-v5-api-for-the-eclipse-paho-c-client/

Although I accept it's better to concentrate on the brokers first.

Thalhammer commented 6 years ago

As @davidgraeff already said, I doubt there is anything in there that would be useful for homie. And even if we would find a use for any of these new features, it would most likely break compatibility with v3.1.1 devices. I don't think it's worth the tradeoff.

rejoc commented 3 years ago

user defined properties could be used to transmit a timestamp with the value of a property. Currently it is impossible for a newly connected mqtt client to know when the current values were transmited.

davidgraeff commented 3 years ago

As soon as all common mqtt libraries (especially those for ESPs and Arduinos) have Mqtt5 support, it might be an option to think about a new spec release that incorporates MQTT5 features.

Thalhammer commented 3 years ago

We have to be really carefull with that though to not introduce incompatibilities with mqtt 3.1 (which is and will be for a long time the defacto standard).