convention
convention copied to clipboard
homieiot
MQTT Version 5 Support
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/
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.
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?
My suspicion is that MQTT 5 support will be slow, so it's best to focus on the current versions.
@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.
@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.
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.
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.
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.
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).