Node-RED Mqtt 5 support

[Steve-Mcl]

Hi Julian.

Firstly, a blog post that nicely sums up the majority of V5 in a 2 minute read: Hello MQTT Version 5.0!

Ok...

@TotallyInformation

@Steve-Mcl

Is it enough that to set userProperties in the msg object or should we use a typedInput to permit the user to map any msg property to userProperties

Could setting from the msg object be considered the Minimum Viable Product (MVP)? Again, that sounds like a sensible place to start. But I doubt anyone could make a sensible answer to this without understanding what other complexities v5 brings

The issue I have with is this approach is getting lumbered with legacy code (to detect if the UI field is empty and the msg contains the property). Suppose we design it to say "Put your user properties in msg.userProperties" instead of adding a typedInput then we will always have to handle this. If we start clean and decide user properties (and perhaps some other v5 stuff) is done via a typedInput from the get go, we dont have this legacy code checking to see if a value was passed in the msg

@TotallyInformation

@Steve-Mcl

is it right to return the user properties in msg.userProperties considering user properties are just one part of the MQTT V5 packet.properties object

Can you expand on this, not quite sure what you mean?

So, most of the (publish) additional features in V5 are passed into the publish call via a properties object attached to the options object.

Reference: Publish properties

Likewise, upon receiving a subscription event, any v5 properties will be returned in packet.properties.

Reference: packet

So, to be clearer, I said "is it right to return the user properties in msg.userProperties considering user properties are just one part of the MQTT V5 packet.properties object"

Perhaps it might be clear to say...

"Should we simply pass the properties object from the packet to the msg or extract the properties of packet.properties into the msg selectively"

hope that makes sense?

@TotallyInformation

@Steve-Mcl

How would we permit V5 type connection

• Perhaps change the [x] Use legacy MQTT 3.1 support check box to a drop down with the allowable protocol versions 3 , 3.1.1 , 5 (defaulting to V3.1.1) ?

That seems sensible to me, especially if we are going to add other complexities to the node.

Yeah - it looks ok & makes future changes easy...

(3.1.1 is selected by default)

---

additional thoughts...

There is a lot of stuff in V5 that needs thought (shared topics, responseTopic etc) but after playing with some of the features, I can see no reason why we wouldnt be able to stage the additions incrementally.

Please keep the discussion coming.